Search Results

Thanks to a post on Ohana Slack I learned recently of a new setting that Salesforce quietly slipped into the back end and defaulted to ON. Unless you have been ignoring the news recently, you probably won't be surprised that this new setting relates to AI. Specifically, the setting allows Salesforce to access "customer data" to train AI models. If you're wondering what "customer data" entails, Salesforce never directly specifies. That, to me, means they define it as “the values in every field on every object, custom or standard, that you have in your org.” In other words, they are going to use all of your data to train AI models. Ask yourself who owns or will own those models? [Hint: It's not you.] Setup > Opt Out of Customer Data Access You can find the setting at Setup > Opt Out of Customer Data Access. When you get there, you'll see that it is ON by default. If you don't like this (And I don't!), Move the slider to turn it off. You even have to endure an "Are you sure?" screen. Click again to confirm. As soon as I learned of this I logged into each of my client orgs and turned it off. The Clue Maybe you're wondering why I have made such an unfavorable assumption about how Salesforce has defined "customer data"? Well, if you follow the help link to "Learn More" at the bottom of that setup page, it specifies in which situations this setting is defaulted to ON. It's not defaulted for Government Cloud instances nor if your organization "has decided to opt out, or has previously opted out, of sharing Customer Data with Salesforce." More Nuance I was pointed to this help article for a little more explanation of the setting. And I understand that, particularly for predicative AI, most organizations aren't going to have enough of their own data to train models. So I can understand the argument for there being a benefit to training global predictive models. I actually wrote in 2022 about trying to use Einstein prediction builder and the fact that few orgs have enough data to develop predictions on their own. I will also note that this setting "doesn’t affect Salesforce’s zero-data retention (ZDR) policy with third-party Large Language Models (LLMs)." So [at least for now] this setting is only about training predictive AI and not about training generative AI. If you read my follow-up article about Einstein Prediction Builder, you may remember that I didn't find it that useful, even using the "pre-built models" from Salesforce. And ask yourself if you've heard anyone else talking about Einstein Prediction Builder in the last several years? The freemium version of Prediction Builder also looks like it's gone away. So is there even any benefit to us if Salesforce works on these models? Or does the benefit mainly accrue to the company that will come around trying to sell them in the future? A Violation of Trust Regardless of how hard it might be to build good prediction models, that does not justify taking your organization's private data without affirmative consent and without compensation. Salesforce constantly touts Trust as their "#1 value." Dropping a new privacy-piercing setting into your system and defaulting it to ON feels like a major violation of that trust. I also just don’t like the idea of handing over my nonprofit clients' data to train a model that is going to make billions that won't benefit nonprofits.

A while back I wrote about a solution I built, using Flow, to solve the annoyance around user ownership of a File when you want to delete it. You probably won't be surprised that's not the last time Files have given me a headache. (Same client, in fact: For Pete's Sake, a great little organization.) As usual, this was a totally reasonable request. They wanted to include a scan of a lovely handwritten Thank You Note created by the family on respite and send it to the doctor that nominated them. Hat Tip to Andy Utkan for this blog post on Salesforce Break that helped me understand how to make this happen. Hide and Seek First step: I have to find the file in question. Good news, I know where it will be! It's uploaded as a File attached to the triggering record (of a custom object called Respite) that fires our record-triggered flow. We even have an agreed-upon naming convention to ensure that the thank you note is distinguishable should there be other attached files: the staff upload with "TYN" in the name. Shouldn't be too hard, right? Nope. Guess again. We're talking about Files in Salesforce, or, as I think of it, the ContentWhatever architecture. There always seem to be at least four objects involved! Plus there are special [Specially annoying!] ways you can't work with ContentWhatever in SOQL. To add insult to injury, for some unfathomable reason, I can't even find an ERD (entity relationship diagram) to try to understand the ContentWhatever system visually. Poke around the developer documentation for a bit and you learn that ContentDocumentLink is what attaches a record to a ContentDocument. But don't forget about ContentVersion! I know you care deeply that Salesforce handle file versioning for you. And while we're at it, notice the special note on that page about how queries won't return all files a user has access to. See what I mean about SOQL for ContentWhatever? Add in some trial-and-error and I confirmed that the Send Email action is going to need the Id of a ContentVersion to use as an attachment, not a ContentDocumentLink, not a ContentDocument. So we have to find: A ContentVersion of a ContentDocument, whose name contains "TYN," that is connected via a ContentDocumentLink to our triggering record. Thankfully, it's safe to assume there will be one and only one. (Or at least we can just use the most recently created one.) But we can't just do a Get Records with anything like that list for filters—oh, no, that's not how ContentWhatevers roll. Can't do it with a simple SOQL query either, so UnofficialSF's Execute SOQL action for Flow won't save us. How To Solve It Taking basically all the steps in Andy's blog post, I had to: Get all the ContentDocumentLinks where the LinkedEntityId = our triggering record. Transform that collection into a list of ContentDocumentIds. Get the the ContentDocument whose Id is IN the list of ContentDocumentIds AND whose Title CONTAINS "TYN". (We narrow it down to only one by sorting by created date and taking only the newest.) Check to ensure that a ContentDocument was found. (Because your email will error if you try to send with an attachment but have none to attach.) Use the LatestPublishedVersionId from the found ContentDocument. {!SecondGetRecordsStep.LatestPublishedVersionId} Yes, that's a surprising number of steps. It looks like this in the relevant section of the flow: Then on the branches after the decision we either send an email with an attachment and language about it or a version that has neither.

I recently had problems in two different client orgs where users found evidence that a screen flow wasn't working. Different screen flow. Totally different set of actions it was supposed to take. But the users noticed that emails apparently weren't sent. Or fields weren't updated. And these were both screen flows that had been thoroughly tested and had been in use for months, if not years. I'll give you a screenshot of one of the screen flows that had the problem. Click to enlarge, if you wish, but there is no need to pay attention to the actual details of this flow: Here's a simplified representation of how most screen flows work, and plenty representative of that one: To list it out, it goes like this: Get some records (or do other logic). Present a screen to the user. User clicks Next. Do some logic based on the user input. Present another screen to confirm for the user what is about to happen. User clicks Finish. Do final actions and logic. But can you spot the major flaw? I would estimate that at least one in ten runs of this flow will do absolutely nothing. Hints: It has nothing to do with any of the component settings. Fault paths would not help. Did They Finish? The problem is that the actions in step 7 take place after the user clicks Finish. It's subtle, but think about it for a second: What if the user never clicks Finish? Yes, it's a big, bold, tempting Finish button. And I've been known to use language like "after you click Finish..." to describe what's about to happen. But there is still a non-zero chance that the user will abandon the screen flow as soon as they get that final screen. They could click away from it to elsewhere on the page. If it opened in a modal, they could click the X to close the window. (I'm sure there are other creative ways that haven't even occurred to me.) And it's virtually impossible to actually track this—there's no logging of the action a user didn't take. I guessed that this was happening in both cases of my clients whose screen flows "stopped working" and when I asked the users in question, they admitted it was likely what had happened. The Fix: Finish Before Finish This is clearly easy to resolve. Just move all the actions of your screen flow to before the point where a user would expect they have already happened. There are always going to be reasonable use cases for launching a screen flow and then canceling it, of course. But at any point that the user might think the flow has acted, you need to make sure it already has. So for my simplified flow, edit to look like this: On the real flow, I just had to move a few things around at the very end. This, with the Update Records step at the end: Became this, where the update is complete before the final screen: I've pretty much come to the conclusion that the last screen in a screen flow should always be the absolute last thing on the canvas (other than a Navigate Everywhere component, perhaps). All actions and logic take place before it looks to the user like the flow is complete. That might mean I have one more screen, so they have a chance to consider an action before clearly clicking "Take Action", and then at the end they get a confirmation screen that's just window dressing.

Our beloved community of nonprofit Salesforce practitioners needs to have some deep and important conversations. And not just in little one-on-ones or side notes to other discussions. I'm not sure who all the right voices are to include. I've failed, so far, to bring interested parties together. And, let's face it: my voice, in particular, might be more of a distraction than a help. Besides, I'm not sure how, when, or where to convene these discussions. But in case it's helpful, I can articulate the What and the Why. What: the future for nonprofits using Salesforce What we need to discuss, in case you haven't figured it out from my previous posts, is on the future for nonprofits using Salesforce . At the moment, we've got potential for quite a bit of chaos when nonprofits look at adopting Salesforce (or those already on the platform consider the future of their instance). Five years ago a nonprofit about to adopt Salesforce was overwhelmingly likely to use the Nonprofit Success Pack (NPSP). The few that didn't choose NPSP had specific reasons, like an earned-revenue model where Sales Cloud was right for them, or a plan to use another specific app. Functionally, this meant that when we spoke about "nonprofits on Salesforce" we were talking about NPSP or at last orgs that have NPSP as a base to other customization. But since the launch of the Industries-based Nonprofit Cloud (now "Agentforce for Nonprofits" or "AFNP") we have already seen a bifurcation of the market for new instances. Of course, the vast majority of the installed nonprofit base is still on NPSP. But Salesforce is selling AFNP hard , for all kinds of reasons (including, but not limited to, profit margin). And, starting in December, Salesforce has even removed the option of getting your org provisioned with NPSP pre-installed. [For the record: You can still get NPSP with your new P10 donation. You just have to install it .] From the very launch of Nonprofit Cloud people realized it was going to have ... How shall I put this? ... gaps. That is to say, there were things that were too complex, or confusing, or poorly documented, or components that didn't work well . I was there for the initial conversations that lead to the NPC Best Practices group of the Open Source Commons. Kudos to them for the work they've done and are still doing toward making AFNP more understandable, easier for admins (and consultants) to set up, and just more usable for more organizations. At the same time that Salesforce is pushing AFNP and NPC Best Practices is working to speed up its maturity vis-a-vis the marketplace, others are deciding that the Industries- and person accounts-based model is just not a good fit. Besides me, there isn't much public writing about this for many reasons (but mostly money). But consultants have conversations with their clients. People have conversations at user group meetings, on the margins of various events, and one-on-one all the time. People are even stepping into the breach to offer products on the platform with the kind of functionality NPSP offers, but without the dependency on support from stock ticker CRM. Idlewild has been publicizing their Nonprofit Accelerator (NPA) and thinking about how to make it available more widely than just to their clients. I raised a question at the 2025 Denver Community Sprint that become the Nonprofit Bridge project. And recently Laura Meerkatz forked NPSP's code to create a new community-owned version called NPPatch . There are almost certainly other efforts happening that I haven't heard about yet. (I've also heard more than a few consultants asking the question, "Are there other CRM alternatives that I should recommend for clients of my size/type?") On the one hand, these three projects are great! This is a revitalization of the community. It shows a level of interest and commitment that I applaud. It sounds like the kind of energy that created NPSP in the first place, before Salesforce.org took it over. On the other hand, we're duplicating effort and we're neither coordinating nor communicating. We haven't answered questions like: Do we (as a community) want/need an alternative to AFNP? If so, is NPSP still that alternative? Or NPA? Or NPPatch? Or should Bridge build something of its own? Are we OK with having two "camps" (AFNP and NPSP), or three, or four? Who should own, publish, and support the product(s) that nonprofits adopt? Major kudos to Laura for opening discussions  on her repo about exactly these questions. But she hasn't gotten much traction there yet. (And maybe the Discussions tab of a GitHub repo isn't the right place. Plus it’s the discussions of a specific repo.) Bridge got a lot of interest in Denver and many people signing up to its LinkedIn Group . But more enthusiasm than discussion. And Idlewild initially started to launch a partner program for NPA in the fall, then put that on indefinite pause for internal discussions. So these conversations are just not happening yet. Why: the future for nonprofits using Salesforce [See what I did there? The What and the Why are the same thing!] These conversations are important because they impact the very idea of whether nonprofits will continue to use Salesforce in similar enough ways that we can have a "nonprofit Salesforce community." As long as it continues to be "free" for nonprofits, there will be organizations trying out this platform. But if they're all using different configurations, then they'll only have similar challenges (like how to raise money, how to engage constituents, how to track outcomes) but not similar solutions to share. Start the Conversation! Sticking with my normal every-two-weeks schedule, this post is going to go live the morning before Nonprofit Dreamin 2026 . That's coincidental but very fortuitous timing. Lots of nonprofit Salesforce practitioners will be in the same place. Some of the leaders of the projects I've listed will be there as well. I'll be there. I'm sure a lot of you, my readers, will be there. Let's talk. And when the conference is over, let's continue talking on the Trailblazer Community, on Ohana Slack, at TDX and Dreamforce, and Dreamins, and sprints, and everywhere else.

There are all kinds of scenarios in which we find ourselves with a list of people that we want to add to a campaign but we know the list includes a mix of existing Salesforce contacts and people that might be in the database yet. Happens all the time, right? Maybe you get a handwritten sign-in sheet. Or someone emails you the list of people they want to add to an event. Or you're combining lists from several people. In this situation, what we really want to do is an “upsert” of contacts (Upsert means “ up date them if they exist, otherwise in sert them as new records.”) and also add those contacts to a campaign. I suppose, depending on what we're doing, the campaign might already be in Salesforce or we need to create it for this import. Let's assume the simplest scenario: We have a simple sheet of people that includes three columns: First Name Last Name Email In addition to those three columns, there are two additional pieces of information we presumably have, either on the spreadsheet already or at least in our head: Which campaign we want to add these people to. (Either we know the campaign exists in Salesforce or we know it does not and we want to create it.) What campaign member status each person should end up with after this import. We also know (or at least suspect ) that the emails on our spreadsheet might be a mix of the values we have in the personal, work, and alternate email fields for our existing contacts. ( Because the world is just fun like that! ) With only access to regular import/export tools we would have to work on this in multiple steps. Download a list of contacts and use vlookup to find Salesforce Ids for those that exist. Then insert those that don't, get their contact Ids and add them to the spreadsheet. Then import a list of campaign members for all the Ids. What a pain in the butt! NPSP Data Import Object to the Rescue! Usually only used for the initial data load to a new implementation, the NPSP Data Import object  is really handy for this need! If you're working in an NPSP instance (and most nonprofits are), you can do this in just three simple steps: Load records of the NPSP Data Import object from your spreadsheet. [Optional] Do a dry run of the processing of those records. Process those records into the database, creating contacts, campaigns, and campaign members. 1. Load to the NPSP Data Import Object NPSP Data Import is a simple holding object. It has many fields on it that correspond to fields on contact, account, opportunity, campaign, etc. Records of this object do nothing special, they just wait to be processed to become multiple records. In the case of our spreadsheet, use whatever upload tool is handy to end up with one NPSP data import record for each row of the sheet. Those records will look like this, with values in Contact1 First Name , Contact1 Last Name , one of the Contact1 email fields, plus Campaign Member Status and Campaign Name . If you use Campaign Name, expect Salesforce to either match on that campaign name (Exact match!) or to create a new campaign with that name. If, on the other hand, you want to select an existing campaign, just fill out the Donation Campaign Source lookup field (highlighted with a red rectangle). An important note about Campaign Member Status : The Campaign Member Status field on the NPSP Data Import object is just a free text field. There is no validation that the values you use here will match the campaign member statuses of campaigns in your instance. The importer will create campaign members with whatever status(es) you give it. So be careful to only have values in your spreadsheet that match the values you normally use. "RSVP Yes" is different from "RSVP Y" and from "RSVP-Yes" and from "RSVP - Yes". They're subtle differences, but if you aren't consistent with your campaign member statuses, they can be annoying ones! 2. [Optional] Do a dry run of the processing of those records. Now that you have several NPSP Data Import records created by your import, you can go to the NPSP Data Imports tab. There, you'll see all the records that are ready for processing. The Import All Data Import Records button will bring you to the NPSP Data Import screen. Though optional, it's generally recommended to do a dry run before your final import, which allows you to see how the system would match or create records. 3. Process Records Into the Database Once you're confident that things are going to go smoothly, just go back to the NPSP Data Import tool and click Begin Data Import Process, which will do the final processing of your records into the database. Contacts are upserted (matched or inserted) and added to the campaign, which was itself matched or inserted. How cool is that!?! Other cool tricks: So. Many. Fields. I only talked about three data fields (first/last/email). But the NPSP Data Import object has fields for multiple emails, salutation, title, preferred email, preferred phone, account data, and much more. You can also use the object's power for a whole lot more than just adding people to a campaign. See the full documentation . You don't have to work on only one campaign at a time! Though I wrote this post focusing on a sheet of people to be added to a single campaign, you aren't limited to that. Put in some people with one campaign and others with another and you'll end up with two campaigns populated at once. Nice! Unduplicated Contacts Go ahead and put the same person on two rows of your spreadsheet with different campaign names. The data importer will not duplicate the contact, but it will put him into two campaigns (with different statuses, if that's what you had on your import).

Well, Marc Benioff managed to do it again . If you thought his interview in October was bad, now you don't have to wonder if it was a one-off. This time he asked international employees (that his company had just flown to Las Vegas) to stand, as though they were about to be recognized positively, then "joked" that ICE was waiting in back for them. Into the deafening silence from the company, Parker Harris eventually said that he was "not OK" with Marc's comments. That alone would have been too little and too late. But he followed up by basically threatening employees that speak out about this with firing. Sigh. I don't have much more to add here than has already been said better than I could in LinkedIn posts ( here , and here , there are many more), threads on Slack channels, and the like. But I decided that I don't want to just ignore this either. I owe it to the Salesforce employees and the broader community—actual feeling humans, regardless of whether they were born in the US or abroad—to use my platform to say two things: This is unacceptable. It was insensitive, mean-spirited, and truly shows us just how disconnected tech bros are from real people. I think the board ought to remove Benioff over this. I actually think this may be grounds for just about anyone to claim that Salesforce is a hostile work environment. I hope someone sues. Salesforce should be punished for this kind of behavior by its CEO. (And Wall Street ain't likely to do it.) Benioff Said This, Not You To employees of Salesforce: I feel for you. I sympathize with what you must be going through. I can't really imagine how crappy it must feel to work for someone so hateful. There are many of you that regularly interact with the community. I think you do it with respect. I've found most Salesforce employees to lead with compassion, humility, and understanding. Thank goodness you're not learning from the example of your CEO! I'm sure that since this happened, some of you are taking heat that you don't deserve. I don't claim to speak for anyone but myself, but I hope you know that we in the community have your back . If you need (or want) to stay in your job (for all kinds of reasons), that is OK. If you feel you need to quit over this, I will be here to support you in whatever ways I can. I Wish I Could Do More It would be nice to think we could really punish the company for keeping Benioff in leadership after comments like these. I just don't see many avenues that I think would be effective. The stock market has been punishing the company's share price for more than a year. No one could truly say if any recent drop has to do with the recent mess. But trusting Wall Street and capitalism seems rather naive to me anyhow I'd love to see people boycott Salesforce's signature events like Dreamforce, TDX, and World Tours. But again, it's hard to know how this would truly send a message, since there will always be some people attending (they need to for their business) and the motives of those not there are rather hard to measure. I can tell you right now that my heart wouldn't be into going to any of those events right now. But I'd cooled on the big events already because I think the community-organized not-sponsored-by-Salesforce Dreamin events are so much better for learning and networking. And then there's the question of using the platform or not, recommending the platform to a new nonprofit that needs a CRM or not. Unfortunately, as I've written before , I don't see a viable alternative. I'm using a technology because it works and I'm supporting my clients that are already on Salesforce. I'm not going to pretend that the company behind the platform somehow is also improving the world.

Today I'm offering a quick gift. Nothing fancy. Nothing a lot of you wouldn't already know. (But I've found a good number of admins out there that haven't discovered this yet.) You know that annoying little notification at the bottom of the Flow Builder canvass every time you work on a flow that always has a notification bubble on it? In case you need a reminder, I'm talking about this one: The one that is always pestering you about not having pink elements within a loop. Even if you don't have a loop! ( Here is a brand new flow with no elements on the canvas at all, much less any loops: Please explain to me why it's already got a tip for me.) Have you noticed that the tips rarely have much by way of useful advice anyway? I know you've seen this box. I know you probably are annoyed by it. If you're like me, the fact that it has a notification bubble draws the eye and the fact that you can't dismiss the notification is infuriating . Today I'm here to tell you that you can make it go away. ?>Mute Tips The function you're looking for is called "Mute Tips." Simply click on the question mark help menu in the upper right of the Flow canvass and select the last option, "Mute Tips." Gone! Just like that! And this selection will persist. So the next time you open this or any other flow, no more annoying notification bubble! Hooray! 🥳 🎉 Unfortunately you'll have to do this fresh in each environment. The next time you spin up a sandbox to work in a new flow you're going to have to mute the tips again. But at least you have the option. Unmute Tips if you Desire If, for some reason I can barely imagine, you decide you want the tips back again, you can unmute them in the same place. You're welcome.

It's quite a while ago that I wrote about having test data in your production org . ( I'm still a fan.) But recently I set up an additional way to work with those test records: formula fields that designate a record as part of your test suite. My client For Pete's Sake (FPS) really needed this trick. FPS has quite a few contacts that are test records and they come from various franchises or no franchise at all because they've been created by different people at different times for slightly different reasons. That makes it pretty hard to keep track of them all. Let's just list some of who they have: Patient Homer Simpson, his wife Marge, and children Lisa, Bart, and Maggie . They went on respite several months ago. Homer and Marge share phone numbers with a couple of FPS staff so that we could test notifications asking them to complete pre and post respite surveys. Patient Wonder Woman and her caregiver Spider Man went on a later respite. They, too, shared phone numbers with real people. Micky and Minnie Mouse have also gone on respite and filled out surveys. There's a doctor Frank Enstein who has nominated some of his patients for a respite from FPS. ( That one still makes me giggle. Kudos to Pam, the FPS staffer that came up with it. ) On quick glance in a report or list view he is not obvious as a fake! The Flintstones are in there. And then there are Im Testingagain and Atest Nominator, both of whom I get the blame for. (I wasn't feeling creative by the umpteenth iteration of testing a FormAssembly form.) Etc... We created several of those patient and family groups in the fall, when FPS was testing a new mobile app they'd launched for patients and caregivers that includes their surveys. We needed to be certain the SMS notifications were going out and that surveys completed in the app flowed through the integration to Salesforce. And then we needed (and still need) to keep those test patients going so that we get the follow-up surveys at 1 month, 3 months, 6 months, 9 months, and 12 months post-respite. We can't restart and reuse those same people as though they're newly nominated or we'll lose our test of the ongoing follow ups. This also means we might add some new test records during upcoming respites if we find we want to test other things. But that's not all! For each patient in the FPS program we have onboarding records and respite records as well. Those are related to the contact by a lookup field and are auto-numbered. So even if the patient name were an obvious test record, the respite or onboarding might not be. For Pete's Sake also uses leads for the initial nomination of a patient by their doctor. So we're going to have some test records in the Lead object, either as new nominations or already converted into some of the contacts above. ✅ Formula Field to the Rescue Easiest way to know if a contact is a test record is to have a field that is automatically checked if they are. No magic here, that's just a checkbox formula called Is Test Data . There are several ways you could approach making the formula that actually controls this field. One way or another you're going to be hard coding something into this formula by which you, the human, are directly telling Salesforce that this record is a test and all others are not. I haven't been able to come up with an alternative to hard coding. And don't forget that if you add test records, you're going to have to edit this formula to account for them. What you hard code is up to you. One option would be to hard code record Ids. As long as nobody goes merging duplicates of your test records, those Ids won't change. I decided to actually hard code the names of the people themselves so the formula would be easier to read: ( FirstName = "Spider" && LastName = "Man" ) || ( FirstName = "Wonder" && LastName = "Woman" ) || ( FirstName = "Mickey" && LastName = "Mouse" ) || ( FirstName = "Minnie" && LastName = "Mouse" ) || ( FirstName = "Fred" && LastName = "Flintstone" ) || ( FirstName = "Wilma" && LastName = "Flintstone" ) || ( FirstName = "Bam Bam" && LastName = "Flintstone" ) || ( FirstName = "Homer" && LastName = "Simpson" ) || ( FirstName = "Marge" && LastName = "Simpson" ) || ( FirstName = "Bart" && LastName = "Simpson" ) || ( FirstName = "Lisa" && LastName = "Simpson" ) || ( FirstName = "Maggie" && LastName = "Simpson" ) || ( FirstName = "Blank" && LastName = "Suzie" ) || ( FirstName = "Frank" && LastName = "Enstein" ) The formula on Lead is exactly the same. I could have consolidated a bit by just using LastName = "Flinstone" because I strongly doubt there are real people with that name. But that would barely matter. Formulas on Other Objects Here's the part where you have to know your instance: Do you need formulas on related objects to know if they go with a test record? In FPS's case, the answer is Yes. We needed formulas on Respite and Onboarding because they're related by lookup, not master detail, and there are a couple of fields that could mean they're test data, if either the nominee or patient is fake. (Hopefully it's either both or none, but people make mistakes...) Onboarding, for example, has two lookups to Contact, for the nominee and their caregiver, so we have this formula field: Nominee__r.Is_Test_Data__c = true || Caregiver__r.Is_Test_Data__c =true The nice thing here is that we didn't have to hard code for the child object's formula field. We just look up through the relationship to the formula field on Contact. If the contact is a test record, we know the onboarding is too. Now Reports are Easy! All those dashboard reports that you've been filtering with Full Name not equal to Harry Potter, Super Man, Homer Simpson... are now a breeze. Just use Is Test Data equals False . No more remembering who all the fake people are. It's easy to flip back and forth to see only the test records. And it's clear for any user looking at report filters to know why that filter exists. Also a handy filter for a related list: As long as you're updating your hard coded formula, this filter keeps up. That's far easier than editing every critical report in the org to filter off the new test record you've just created! Bonus Points Want to really help your users and yourself? Put a banner on record pages to remind you that you're looking at test records. You've already got the field to conditionally display a message. So throw on a Lightning Messaging Utility banner that only shows up when the field = True. I've set up this same banner on Contact, Lead, Onboarding, and Respite. (That was four repetitive instances of the same task, but it took all of five minutes.) Future You and your users will thank you.

A few weeks ago I wrote about the distinction between platform and product . It's a blurry line (at best) with a lot of things in the Salesforce world. I think this is confusion that the nonprofit Salesforce world has been bedeviled by for a long time, particularly due to the fact that most of us use a common tool, the Nonprofit Success Pack (NPSP). I ran across a great illustration of the confusion when I was at NPSP Day Philly the first week of December. ( A great event, by the way. Watch for one near you! ) There were several people at the event that were on the fundraising and development team of a local nonprofit that is known as a place to swim or exercise. (You've heard of them...) Their organization is in the middle of a Salesforce implementation that, honestly, sounds like it's been mismanaged. I'm sure there is more going on than just what I heard from those folk in side conversations throughout the day. But the main thing I was able to gather was that at some point the person implementing basically told the fundraising team that because they had an org with the Nonprofit Success Pack (NPSP), they should be able to "just start using Salesforce" for their development work. [Not a quote, just my way of expressing what I gather they were told.] The implementation had originally been planned to start with program management and I got the impression that nothing was done to refocus the work on fundraising other than tell them to start using Salesforce. That first week in December, that org's fundraising team was using Salesforce but found themselves entirely unable to report on simple things like "How is the Giving Tuesday campaign going?" And from what I could tell, the main obstacle wasn't about not understanding Salesforce reporting. It was fields that weren't accessible, data that wasn't available, and the like. What I realized is that the person telling the fundraising team to use Salesforce is unaware of the distinction between product and platform. He seems to have thought that since they "had" NPSP they could just "start using it." But he'd done nothing to set up the instance to use NPSP features. That is not the way things work!  And just to be 100% clear, this story would be equally true if their org was on Nonprofit Cloud (NPC, currently named "Agentforce 360 for Nonprofits"). Neither "works" from the moment you "turn it on." They require extensive configuration and customization. The folks from this org described being on calls where they asked for, for example, a Gifts This Year rollup. The guy would quickly "do something" then tell them to refresh their page and there it was. I can't be sure, of course, but it sounds to me like in the moment he was simply adding fields to the page layout (or fixing field level security) that should have been there in the first place. They described this happening repeatedly. Basically Nothing Is Preinstalled I've pointed this out before so I'm just going to quote myself: You don't get to convert a trial org into your real instance. You can get a trial and play with it, but when you get your real instance it will be essentially a clean org, perhaps with NPSP installed, but only the package, none of the extras that were part of the trial, including record types, sales processes, page layouts, metadata records for NPSP features (like reciprocal relationships settings), and more. (This is, again, exactly how it works with NPC as well. ) The upshot is that even if you are implementing the most basic possible use case for Salesforce in the nonprofit context—which is to say "a simple use of NPSP/NPC to track donors and donations"—it will not work for users "out of the box." The page layouts will not show things like donation rollups for Total Gifts This Year or Last Year. Users won't, in fact, have permissions to view those fields at all, neither on page layouts, nor reports. When users try to enter a new donation, they won't find an opportunity record type whose page layout has the fields they need, whose stages match the stages fundraisers use, or that can record multiple payments on a single pledge. Users won't be able to send email acknowledgements for gifts. Most of this stuff exists in the back end, it's just not enabled. From the user perspective, they're going to decide that Salesforce is either broken or useless, or at the very least very confusing, and walk away if they can. Sadly, our beleagered friends from NPSP Day Philly don't have the option of walking away. Their contract for Blackbaud/Raiser's Edge expired at the end of 2025. So they had no choice but start doing their work in Salesforce. That means they're coming up with all manner of workarounds to just record something, anything. Who knows which opportunity stages they're setting gifts to? Who knows if they're entering donors in consistent ways? I get anxiety just thinking about it. (And they're not my clients.) The Trials are Products (ish) If you spin up a new trial org (for either NPC or NPSP ), I would say that's a product. What you get with a trial is a fully-configured Salesforce org [presumably] meant to show off how you would/could do fundraising as though Salesforce was a fundraising application, not an extensible platform. Fields are on the pages, record types are enabled, buttons and quick actions are in place, donation rollups calculate, etc... It's basically a turnkey fundraising tool. I would call that a product. [Side note: That first login for the first user is still gonna to be rough . All kinds of annoying pop-ups, all list views go to empty Recently Viewed, some objects have no list views set up at all, you're not immediately in the right app, etc... But plenty of products have less-than-ideal UX when you first use them.] However, since you can't use that trial for more than 30 days, it's not that relevant that the trial is a product . It's not a product you can buy! When you get your real instance, you merely have the platform (essentially Sales Cloud) with a bunch more metadata sitting in the back end. You have to start customizing to even get to the point of having what you experienced in the trial org. I don't think enough people understand this distinction , particularly because this isn't how it used to be. Until a few years ago the process for getting your Power of Us donation was that you created a trial org, put in your Power of Us application, and when that was approved your trial org converted into a full Enterprise Edition. In that world, nonprofits all started with the same product. That gave us a common language and common experience. Moving to Platform But as soon as we customize our Salesforce instance to do more things than fundraising, or to do fundraising in different ways, or to add features to our particular type of fundraising, or to not do fundraising at all but still use the Household Account Model, we move from the world of product into the world of platform. And, frankly, that's where all the power is. NPSP or Agentforce 360 for Nonprofits are just two offerings in the world of nonprofit fundraising software. There are others, including Raiser's Edge. If you lay those three next to each other as products , you have to make a selection for your organization based on features and price. ( What else is there? ) Raiser's Edge might win in that head-to-head. ( Might. ) But what I think makes Salesforce a better choice than Raiser's Edge (for those organizations that have made an informed decision) is that Salesforce is a more extensible platform. If there's a feature of Raiser's Edge that you love that doesn't exist in NPC/NPSP, all you have to do is add it from the AppExchange or build it custom. On the other hand, if you want to add your program management database into Raiser's Edge, you really can't.

Here's an interesting challenge. Modern Classrooms Project, who runs a program for teachers, wanted to be able to show, on the account page, counts of various program metrics. For each of those metrics, they also wanted to make it easy for users to see which records went into those counts. Taken on their own, either request seems pretty easy. If you want a count (such as enrolled participants from this school) you can make a rollup summary field, either standard or using DLRS . And if you want to see the data that goes into that count, you run a report. [In theory, a related list could also fill this need. But if we're talking about having filters on the count or different counts with different filters, having filtered related lists for each scenario will get out of hand. Even for only one count, a filtered related list isn't going to be very functional and probably isn't a good use of screen real estate. And finally, assuming a lot of records meet the filter, it's never going to be as convenient to view those in a related list as it would be in a report.] But together these two solutions don't make for a good user experience. If we show the count on the page, users know the total. But it's not that easy for them to figure out which report they would run to replicate that total. And even if they know the report's name (perhaps we put it in the help bubble), it would be several clicks for them to actually run that report. Idea! 💡 But we can solve this with two fields: A rollup summary and a formula field. Only the second field, the formula, is going to be on the page layout. The rollup summary field is a helper that stays in the shadows. The Rollup Summary Fill the data in this field however you want. If a standard rollup summary field can do for you, great! But if you need relative date filters or other special powers, fill it with DLRS or even a flow. There's no special magic here, just get the metric you need populated into this field. While I'm at it, let me make a plea for documenting the heck out of this field! If it's a DLRS rollup, my naming convention is to start the API name with "DLRS_". And if the field won't be on page layouts, as these won't be, I also leave "DLRS_" in the field label. Note in the description, "Filled by DLRS," particularly since being in a DLRS doesn't result in an entry in Where is this used? And in this case, I would also recommend noting that it's a helper field for the formula, etc, etc. The Formula is the Magic Truly, the magic in my solution comes from the formula field. This is the field you're going to put on page layouts for users. It's going to look like your basic rollup summary field. It's going to show a number. But it's going to actually be a hyperlink. (So I guess it doesn't quite look like a basic number field, since it shows in blue.) The formula for this field is: HYPERLINK( "/lightning/r/Report/ Id_of_your_report /view" & "?fv1=" & Id, TEXT( API_of_your_helper_field ) ) It's outside the scope of today's blog to go deeply into how that formula is built. But a quick overview: It returns a hyperlink, so it will be clickable. In this case it's a hyperlink to a particular report. The two bold blue bits are simple enough: the Id of the report you are redirecting users to and the rollup summary to show the number as what this field displays. The bold middle line is where the report is getting the Id of the record on which we're displaying this formula put into a filter that's waiting for it. (See this Help article .) That's it! Now you can put the fields somewhere on the page and you get a result like this: Not just numbers, but clickable links to reports about each of those numbers!

Salesforce makes a very good platform but not very good products. There, I said it. Some people might accuse me of heresy. [Maybe I'm jeopardizing my partner status or my membership in the MVP program.] Feel free to disagree with me, of course! Obviously, I'm going to need to define "product" because in the world of software engineering just about everything is "a product," in the sense that there is a "product manager" in charge of it. But most of those things that product managers work on are what you and I would call a "feature." (I guess "feature manager" didn't sound like a good title?) I have no beef with plenty of Salesforce features—they're what make up the platform. I think Salesforce's features are great, from reports and dashboards , to the powerful declarative automation tool Flow, to user access, permissions, and record sharing. It's the features that I group together under the heading "the Salesforce platform" and frequently endorse. From the first time I logged into Salesforce I could tell it was a database that was user- and admin-friendly. I have not yet seen another platform as easy to customize, as flexible and powerful, as secure, or as reliable. And as I've written often, thanks to the Power of Us program, Salesforce is quite cost-effective for nonprofits. But Salesforce also offers "products," which I would define as anything for which they charge separately from regular user access to the platform. And I hate to say it, but I don't see a lot of evidence that those products are so great. Some are good, some are not. Just because it has the Salesforce name on it is no particular guarantee of quality. Within its core competency of providing CRM for businesses, Salesforce is a leader. Outside that core competency, I'm less convinced. With no intent to be comprehensive, let me use a few examples to explain what I mean. Professional Services This one confuses me, to be honest. Salesforce offers professional services , otherwise known as "consulting." So...Salesforce has an entire program to certify partners and to grow a partner ecosystem but they also offer the same services in competition with those partners. I don't really understand that. (If I was a large partner, it would probably piss me off, in fact.) But beyond the not understanding, it seems to me there is no realistic way Salesforce's professional services could be any better than what partners offer. Consulting is just too dependent on what a client needs, who the hands-on-keyboard staff are at the consulting company, and other human factors for any particularly consultancy to be consistently better than another. I'm sure Salesforce professional services does some great implementations and some terrible ones. I'm sure they've made some clients very happy and made others very unhappy. They are human! Unless Salesforce's professional services department has special access to special ways of interacting with the platform technology due to being Salesforce , they can't possibly be much different than any other similarly-sized consultancy. I've never heard any suggestion that Salesforce's people can offer special technology access to their clients. (If it were true, that would be very unfair competition with other partners.) So how can their consulting services be materially different from any others? Backup About a year ago Salesforce announced that they had bought Own , the most prominent company offering backup services for Salesforce data. Salesforce actually had their own native backup option once upon a time, but it was apparently not much to speak of, and was fabulously expensive. So in the manner of big tech companies, Salesforce bought a competitor. I hear Own's product is pretty good. Before the acquisition they were quite a bit more expensive than other options, but they had some features to justify the price. So now Salesforce has a backup product to offer. But this wasn't a product developed by Salesforce. [And side note: Many people would actually prefer that their backup service not be handled by the same company that is being backed up. That seems a not-unreasonable position to take.] Forms/Surveys If you've spent any time in the Salesforce ecosystem you've pretty quickly realized that webforms are their own special challenge. There are some fantastic form vendors that integrate with Salesforce. (FormAssembly is my go-to.) But they can be expensive. There is the possibility of embedding screen flows on Experience Cloud sites for free external forms, but that's much harder to maintain. And then there is the Salesforce Surveys product that, frankly, I've never heard of anyone using. 'Nuff said. Data Cloud I am no Data Cloud expert. I don't have the certification and I don't have any clients with needs that Data Cloud could solve. So I don't really have a personal opinion here. But I've heard from several people over the last several years that Data Cloud is fine, but it's nothing special. It might have some easier integration to Salesforce, but that's offset by higher pricing. No knock on Data Cloud here, just an example to show that just because it has the blue cloud logo attached doesn't mean it's necessarily better. Artificial Intelligence (and Agentforce) Let's start by disambiguating: "Artificial intelligence," at this point, is a meaningless catch-all term. It elides the differences between machine learning, predictive modeling, sentiment analysis, large language models, and so much more. Salesforce used to group it's AI offerings under the Einstein branding. Now they're grouping everything under Agentforce. But of course there are still several very different "AI" products. I've written in the past about trying to use Einstein to get insight out of predictive models to see how it might benefit organizations at the scale of my clients. Nothing's changed in that space. But if you hear all the hype, you'd think Agentforce has changed everything about Salesforce. Have you tried creating a new Salesforce support case using the Agentforce chatbot? I have. Or have you gotten an email from a Salesforce AE that was clearly written by generative AI (but not at all labeled that it was written by AI)? My clients have. The support chatbot regularly gives me wrong suggestions for how I might solve my problem and then eventually just asks me a series of questions that is not functionally different from filling out the old form. (But it's slower!) And the emails from an AE that answered questions wrong (including pointing toward nonexistent nodes of the Setup tree) were purely a waste of my client's time and mine. Maybe Agentforce will get better rapidly. Or maybe it's not Agentforce's fault, it's problems inherent in large language models and generative artificial intelligence. But the reality is that Agentforce is a Salesforce skin on top of existing large language models. Salesforce is outsourcing the LLM work to another company, then trying to take the outputs and do something useful with them. To that extent it can't possibly be better than the other generative AI products out there. And honestly, I frequently hear people say that Agentforce is worse . I'm in no position to judge. I think they're all mostly pointless hype. Are Industry Solutions (including Nonprofit Cloud and Education Cloud) product or platform? I would argue that Salesforce's "on core" solutions for particular industries are not "platform" but are, in fact, "product." What you get with Industries solutions are several things: The Salesforce platform. One or more data models . Some template automations (mostly screen flows). Access to few additional features (Omniscript, several Lightning Web Components, Data Processing Engine, Business Rules Engine, etc.) Each Industry solution comes with its own data model, in the form of a whole bunch of new objects. (They're not really standard objects because you can't access them without the right Industries permission set license. But they don't have __c after their object API name.) But a data model is hardly a "product," since it's quite easy to create your own custom objects or for an Independent Software Vendor (ISV) partner to offer objects through a package they sell on the AppExchange. A data model, objects, database tables, .... whatever you call it, it's not something you would probably pay for by itself. You pay for the functionality— the features —that go along with the data model. In that case, I guess you could call Nonprofit Cloud, Education Cloud, or any of the other Industries solutions "product" or a "product/platform bundle," since they have some additional features that extend the Salesforce platform. But either way there is clearly an aspect of product to the Industries solutions. Which gets to the question I really want people to think about: Is this a product I want to pay for? Decide for yourself. But in case you're wondering, I'm writing today because I want to apply this question to Nonprofit Cloud and Education Cloud, specifically. I started by stating my thesis that Salesforce is great at platform but not so good at product. I've given examples to argue the product case. And based on that argument, at a minimum I think it's fair to say that Nonprofit Cloud and Education Cloud are not particularly more likely to be great for nonprofits than other available nonprofit-on-Salesforce options. If you look at a data model  and think it's too complicated. If you look at additional features  and think they're ones you don't need or won't use. (Perhaps because they, too, are too complicated. I'm looking at You, Data Processing Engine! ) If you look at some of the features and know that you could replicate them pretty easily with your own screen flow. Then maybe the product you're looking at isn't for you. And what I'm saying in today's post is that just because the product "comes from Salesforce," doesn't mean it's necessarily the best one. That's all I'm sayin'. Paying for the Platform As I've written in the past , I still think the Salesforce platform has no equal, particularly for nonprofits, due the Power of Us donation, the discounts, and the availability of expert support. But I'm clearly implying that some nonprofits might not use Salesforce's products but will still want to use the platform . And if that's the case they still need options for how to make the platform work for their situation. Which brings me right back to what I've been writing about Nonprofit Bridge .

Last post I wrote about Nonprofit Bridge . While I have a lot of opinions about it, I'm trying very hard to let this be a project with input from multiple voices. But I can't help myself; I'm already thinking about features. I don't like the idea of a minimum viable product, that threshold seems too low. But what would be the minimum lovable product ? First of all, I have no idea if Bridge is going to eventually involve an installable “package” (locked, unlocked, managed, unmanaged, ...?), or merely a GitHub repo of metadata with instructions how you can get that metadata into your org, or something else entirely, People much smarter than I, with better understanding of the pros and cons for various ways of "publishing" or "releasing," will need to discuss. It occurs to me that it's not even clear if the final product should be a simple Open Source Commons project or if we’re going to have to create an independent nonprofit to own intellectual property held in common trust. There is a lot to be considered. But despite all that uncertainty, I think I can articulate a baseline of features that I think small nonprofits need. Individuals Given its roots as a sales tool, with the required dependency of a Contact (and an Opportunity) to an Account, Salesforce “out of the box” does not work for most nonprofits and educational institutions. In the overwhelming majority of cases, those organizations need to manage people as individuals . So the first thing I expect Bridge to provide is a way to do that. The Household Account Breakthrough In 2008 the community first came together to solve that problem. The Nonprofit Starter Pack, which became the Nonprofit Success Pack (NPSP) , began life as an open source project to help nonprofits that wanted to take advantage of Salesforce’s generous product donation . Essentially, they had to answer, “How can we track people as people in this software clearly designed for a business-to-business (B2B) use case in which people (contacts) are tracked mainly due to where they work (accounts)?” The eventual breakthrough that made NPSP so successful, in my opinion, was the creation of the Household Account Model . By automatically creating an account for each contact, to represent their household, NPSP made it possible to track donations (opportunities) and know that money came from an individual, not a company. Putting people together in a household allowed us to understand that the donation (regardless of who physically forked over the cash) came from the household if we need to know that. But if we don't actually care about households, just people, the "Household Account Model" works just fine as the "Individual Account Model." Change the name of the account record type, never put two people in an account together, change the naming convention for [household] accounts, bury the Account field on the contact layout, and you've got a perfectly viable system for tracking people as people. Some people get fussy about the double data usage of potentially having an account for each contact. But personally I don't think that's such a big deal. (And Person Accounts has the same problem.) Affiliations Nonprofits also want to track how contacts are related to organizations, including where they work, other organizations they may support, and the like. In fact, in my experience nonprofits very much appreciate being able to track a history here, rather than just (as the standard Salesforce model has) where someone works right now . NPSP's model of Organization Affiliations and the Primary Affiliation kept the option of tracking where people worked, if we needed to know that, plus any other involvement those people have with any other organizations (including our own). And through that kind of information, we could also see when donations were related to things like employer matching, influence in a foundation, etc. Relationships If you’re trying to understand people, you also care about relationships (spouses, parents, etc.) In my experience, actual usage here can vary widely and most organizations seem to just track a few key data points (like spouses, or guardians of enrolled children). But the NPSP Relationship object is simple and flexible, and the triggers to manage reciprocal relationships are very handy. Fundraising Here, actually, I’m not sure there is a lot of "functionality" need. If you look at what the Nonprofit Success Pack actually does around a fundraising data model, it’s not much: The package includes a Payment object, child to Opportunity, so you can have multiple payments on a gift. There are several opportunity record types. And NPSP also includes a lot of rollups about gifts, but I don’t consider those core as a functionality need because I think they’re no longer that hard to build with other tools. (Like DLRS.) So while clearly nonprofits will need some features around fundraising, it may be surprising to notice that this might not be the most important area. Could This Be Standard Functionality or “Core”? Theoretically, the majority of the MLP that I've just outlined can be provided by Salesforce through out-of-the-box features in 2025, in a way it was not in 2008, when the NPSP was first published. Standard Feature for Individuals and Relationships Person Accounts are the official Salesforce method for managing individuals in a “B2C” (Business to Consumer) data model. Long a sad joke within the Salesforce world, the official company line is that they’re good now and they’re the basis for a lot of Industry cloud solutions, including Financial Services Cloud for wealth managers dealing with their clients. I already wrote, in March 2024, that I haven’t managed to love Person Accounts. Re-read that post for my full review. But spoiler alert: I think they’re terrible. [I’m still open to having my mind changed, either that Person Accounts aren’t that bad or that it would be easier to hide the complexity from users than to do something else. But my current opinion is that we need something better than Person Accounts .] Affiliations in the Sales Cloud Data Model Similarly, you can enable the feature “Contacts to Multiple Accounts,” which enables a history of contacts’ relationships to accounts as they are edited. But the functionality you gain here is woefully underpowered compared to what NPSP does with Affiliations and the automation around Primary Affiliation. Could Contacts to Multiple Accounts be enhanced with some more fields and some more automation through Flow? Sure. But if you’re customizing like that, I see little benefit to using this standard Account History object rather than a fully realized custom object. So yes, standard Salesforce features compete with the MLP that I'm advocating for Bridge. But they are complicated, confusing, and don't work well. They're not a good fit for small nonprofits with limited technical support resources.