Search Results

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.

I just got back from a Commons Community Sprint in Denver and my faith in the Salesforce community is refreshed and renewed. There’s a new sprint project in town and it’s got potential to be an important one, of a scale that the community hasn’t taken on since NPSP was first created. And I’m really proud that people—all of them new to sprinting, many new to the Salesforce community—took to this project enthusiastically, even knowing how big this task could be. I’m confident that as word gets out many more people (that weren’t in Denver) will also step up. [Yes, this should be Freebie on a bridge. But there wasn't time to ask my designer.] Nonprofit Bridge This new project is nothing short of a community commitment to bring forth a choice for organizations that want to use the power of the Salesforce platform to work with individual people but need simplicity, ease of setup and adoption, and low total cost of ownership. We need this choice to deal with some uncomfortable realities: The Industry Clouds and Person Accounts are complicated. People are anxious that Salesforce will stop supporting NPSP someday. NPSP is old technology. Most small organizations have (and will always have) very little in-house Salesforce expertise. I’m going to say more about all of those in a moment. But first I need to contextualize: To the best of my ability, I believe I have captured four statements of objective fact about where the nonprofit Salesforce ecosystem/community stands today. Because of that reality, many people—myself included—believe nonprofits need more choices than the current three: Nonprofit Cloud (NPC), Nonprofit Success Pack (NPSP), or “vanilla” Sales/Service Cloud. [I have plenty of opinion and value judgement that will come later. Disagree with me if you need about the objectivity of those four statements. I’m easy to find via LinkedIn , the Trailblazer Community , Ohana Slack, and elsewhere.] Industries Clouds and Person Accounts are Complicated I’ve written so much about the new Nonprofit Cloud (recently renamed “Agentforce Nonprofit.” But I doubt that’s going to stick. ) that maybe I don’t need to repeat myself much here. [ Just search for "NPC" on this site .] I’ll just show you the entity relationship diagram for Nonprofit Cloud fundraising as a reminder: That's just fundraising! Salesforce designed NPC to meet the needs of enterprise level nonprofits ( That means “big.” ) and sophisticated fundraising operations, so I’m not even qualified to assess whether the complexity is appropriate for the use case. I don't work with organizations of that size or that well-funded. I’m going to just assume this is only as complicated as needed to solve for the use case and not more. But that still leaves it quite complicated. Most small nonprofits just don’t have the sophistication in their fundraising nor the scale of donations and, therefore, could get by with a much less complicated tool. Similarly, I’ve written about the ways that Person Accounts introduce a lot of complexity and confusion . Opinion here: I do not believe it’s really feasible to hide this complexity from users . Even if it were technically possible to do so with things like screen flows, Lightning Web Components, tab renaming, or the like, that will introduce significantly more complexity in the back end that will impact system admins at these nonprofits, most of whom work solo, are accidental admins, and have more to their job than just care and feeding of Salesforce. People are Anxious about the future of NPSP As I have said many times in person and in writing , I do not believe Salesforce has any current plans to stop supporting NPSP . Those organizations using it can continue to do so indefinitely. New orgs can install it. We have not reached “end of support,” nor “end of life,” the code is still visible , and when bugs are discovered or support is needed, Salesforce has continued to act. But despite that demonstrated level of continued support for NPSP, people are still anxious about when or if that will change . Can you blame them? Frankly, I have a level of anxiety too, for all the reasons I’ve spoken about before. There are objective reasons to be anxious. Maybe the level of anxiety is higher than it “ought to be,” or maybe it’s lower. But it’s there and we should name it and respond to it appropriately. NPSP Is Old Technology We reached “end of innovation” many years ago. NPSP has barely gotten any new features since I joined the Salesforce ecosystem in 2013. The code is old and, as I understand it, very complicated, and, for example, the package uses workflow rules rather than putting non-code automation in Flow. With the shift to new Nonprofit Cloud, Salesforce officially announced that NPSP would no longer get updates other than support. It’s old tech, it’s not going to be updated or refreshed. Again: objectively true. And we know that old technology doesn’t last forever. (Just a surprisingly long time. See: COBOL , vinyl records, Salesforce S-Controls, …) But even if we can be reasonably confident that NPSP will continue to work, before I implement a new org on NPSP I need to at least acknowledge that I’m about to use older technology. I might make the choice to go ahead, but I want to do it with eyes open. Small organizations have little in-house Salesforce expertise I’ve said before that I think the barrier to initial entry to Salesforce is higher than it was a few years ago. Initial implementation is not as straightforward as it was when you could just get an NPSP trial and convert it to a production org. Plus the platform itself has grown more complicated (and more powerful) and other considerations have changed as well, most importantly: security. For all those reasons, smaller nonprofits might choose some other CRM or leave the platform rather than adopt Nonprofit Cloud unless they have another choice that can make sense . That’s the understanding that led to the Nonprofit Bridge project. What Will Bridge Be? The team at the Denver sprint had a little fun mashing up a famous Denver sculpture, a famous bridge, and a unicorn. I don’t think we know, yet, what the Nonprofit Bridge sprint project is going to “produce.” As much as we want to jump into “solutioning” and building things, we’re trying to move forward with humility. So far, only the voices of about twenty people have been in the discussion—that is not representative of this vast nonprofit and education Salesforce community. So for first steps we want to raise awareness that conversations are happening, we want to bring more people and their ideas into the mix, and we want to grow the pool of volunteers to help with whatever “we” decide needs doing. (“We” is meant to stand in for “the community,” not just “those working on the Bridge project.”) But that being said, Bridge already has a statement of vision and values: Vision: We see a need for a future-proofed entry point for nonprofits to the Salesforce platform, where every organization can choose the level of complexity that meets their needs. We aim to design a modular suite of features that can extend the core platform to support common nonprofit CRM needs. Values: Accidental Admin-friendly Turnkey Community Owned and Maintained Reasonably Future-proof Accessible Design No harder migration path/streamlined path to future migrations Declarative first/low code Unmanaged, for maximum transparency No technical decisions that would limit future innovation I actually think that's some pretty heady stuff! So here’s a quick call to action : If that vision inspires you, follow this LinkedIn group , join discussions in the #nonprofit channel of Ohana Slack , watch this and other Trailblazer Community Groups, and consider coming to future sprints to directly volunteer with this project. Next week : Starting to think about what needs to go into a Minimum Lovable Product.

Your friends and family probably heard a lot more about Salesforce in the news than usual in mid-October. Despite the PR and marketing blitz that is Dreamforce, they weren't really hearing about technology, innovation, nor products. Whatever your personal politics, I think we can all agree that's a public relations failure for the company. Thanks to my biweekly publication schedule and the fact that I already had one post in the pipeline, by the time you're reading this we're already several weeks past the initial furor. But let me remind you of a bit of timeline: On October 10th— the Friday before Dreamforce — The New York Times published an interview with Marc Benioff during which, among other things, he'd said he thought Trump should send the National Guard to San Francisco. This was obviously a foolish PR move, drawing attention to his politics instead of his company or its products during the week before its major conference. And it raised some serious red flags among Salesforce professionals, particularly those of us in the nonprofit sector. Then on the 16th (during Dreamforce) there was reporting that his comments drove away a prominent VC that had been a Salesforce Foundation board member for over a decade and comedians scheduled to perform at Dreamforce dropped out . The day after Dreamforce concluded, the New York Times again had a Salesforce story on the digital "front page" about how Salesforce is pursuing contracts with ICE . (And let's not forget that Salesforce has worked with ICE for years, something employees were upset about in 2018 .) Then after Dreamforce Benioff tried to do an about-face and apologize for his comments about sending the National Guard. Say what you will about the relevance of keynotes and product announcements, but during Dreamforce you'd expect Salesforce to eke out more positive coverage. First: Disclosure Nobody's in the dark about this, but I'm going to just state it explicitly: I tend toward the progressive end of the political spectrum. I've been involved in Democratic Party politics at times, as well as generally supporting progressive issues, causes, and organizations. I don't actually have any direct involvement with politics at the moment, but I'm not an entirely disinterested observer of the news or politics, neither local, national, nor international. Is that clear enough where I am coming from? Is Salesforce different? I think I've said this before, but I don't really consider Salesforce different than any other big tech company, or publicly traded company, or, frankly, just an American corporation. I see very little difference between adopting Salesforce and buying any of the other things an organization uses to operate. Nonprofits buy supplies at Costco, ride Ubers, fly on Boeing planes, choose (generally) between Google Suite and Microsoft 365, and use Apple's iPhones and Macs unless they use Androids and Dells. And when nonprofits buy those products and services, they generally don't spend a lot of time hand-wringing about it, in my experience. To pick on just one company in that list: Apple CEO Tim Cook has also sucked up to Donald Trump, "awarding" him a gold and glass plaque recently. That was gross. And cynical. And maybe I missed it, but I didn't hear chatter about nonprofits needing to stop using Apple products because of it. And even if there were such discussions, what are the alternatives? That wasn't meant to be whataboutism . It was meant to illustrate that I start from the assumption that no company is angelic, least of all the larger giants of the American economy. But organizations—nonprofits included—still have to operate. Even the most committed environmental organization uses some plastic and fossil fuel-derived energy. Even the most radical anti-capitalist organization in the United States has to raise and spend money. Were Benioff's recent statements different? If it wasn't obvious from the way I framed that news recap above, I consider Benioff's comments to be problematic, even offensive . They certainly help cement my opinion about him as a person. But I don't find what he said surprising .  Just search for "capitalism"  on this blog, for example. For me, in the end, it just comes down to whether or not I care what Marc Benioff has to say about any particular [non-Salesforce product] issue. I don't. Sure, he has some degree of influence because he's rich—that's why there was a newspaper interview in the first place. But he's not even a politician or policymaker. This is "Crazy Uncle Marc" spouting off. It's no different than your uncle saying things at your Thanksgiving dinner. It might roil some family relationships, but it's not going to actually change anything in the world. Is the sales push to ICE different? I also read the reporting about the sales push to ICE pretty carefully. As I read it, the article boils down to “Salesforce is trying to land ICE contracts.” The details about what they’re saying and how they’re running the sales strategy are the exact same kinds of tactics we’ve been deploring for years now. This is, perhaps, a bigger contract for a bigger amount of money than a lot of others. But I didn't see anything new. Salesforce is a sales machine , with all the icky, ethically questionable tactics and overhyped language of a stereotyped used car salesman. We've known this for a long time. There's a reason I had my illustrator create this image and have used it several times: So as regards the sales pitch to ICE, I read it and thought, "There is nothing new here." It seems like they're using exactly the kind of sales language you would expect them to use going for a government contract in the current moment/environment. If they're working on renewals with State, HHS, or the Pentagon, I'm sure those pitch decks are pretty "cringe" [as the youth say] right now too. Were some on the Right happy? I acknowledged my left wing bias earlier. I guess I should also note that maybe Benioff's comments will have endeared him to some on the right? (Though at least initially Fox News simply took the opportunity to deride Benioff and Salesforce for "promoting transgender ideology. ") Certainly it seems like the top of the US government regime requires comments like this out of billionaires to keep doing business. So as gross as I think Benioff's comments and the sales push for ICE contracts were, I don't want to lose sight of the fact that about half of the country might actually consider this stuff a benefit. I don't know. 🤷🏻 It's hard for me to get into the MAGA mindset. And let's not have any illusions: the US-based portion of the Salesforce community is likely about half Trump supporters, just based on simple demographic statistics. I'm pretty sure the nonprofiteers among the Salesforce community skew left, but we are not the whole of the Ohana. Let's Name It: The Problem is Capitalism So I'm just going to come out and say it: The problem is not Salesforce and it's not Marc Benioff, it's capitalism, particularly as practiced in the United States in the early 21st Century. There are all sorts of things I would like to change about the system in which we operate. The power of giant tech platforms is vast and existentially perilous, particularly for progressives. (See this article .) The media is chock full of warnings about the downsides of generative AI, yet more and more people use it unthinkingly each day. People use their cell phones while driving.... In the end I can only do so much to change that system or to opt out of it. To the extent that I'm still in it, I have to reconcile with the options available to me. This is not an argument against radicalism, simply an acknowledgement that on any issue there is always some line at which we must compromise or die. So what should we do? Of course we should still pressure Salesforce to be better. (Speak out. Vote for this Idea . Perhaps it's time for some other action within the community...) But when it comes to the question of whether we [nonprofits] should continue to use Salesforce, what is the decision matrix? In my opinion it's the same as it always has been: Is Salesforce a good value for the cost ? If you're at the point that your organization needs "a system" and you are careful with your spending, I think Yes . Others may answer differently. Does it make my operations more efficient and effective? That really depends on how you use it and how it was implemented, of course. But it definitely can and should. If I adopt this technology, can I support it? I kinda' think this is the point of Free Like a Puppy. What alternatives could I use to do the same job? [And what are their costs, features, etc...?] AirTable, HubSpot, Zoho, Neon, and others get mentioned. I have no opinion on any of them. I will assume they're all fine, perhaps even great. If they meet your need, go for it! Some can only do one thing well. (Such as fundraising or email marketing, but not both.) None of them has the scale of the Salesforce community to turn to for support. As I understand it, they're not as flexible and customizable as Salesforce, nor can you test and learn about them with tools like developer orgs and sandboxes or sites like Trailhead. By the way: I have no idea who their founders and CEOs are. But I have no reason to believe they're fundamentally different than other tech founders. Unless the platform itself is nonprofit, then their shareholders and boards are eventually going to ensure that they operate like profit seeking companies. For-profit companies choose Salesforce more than those alternatives. If nonprofits can use the same technology as better-resourced organizations, that's probably to the benefit of the nonprofits. A disappointing place to come to, perhaps. But I try to call 'em as I see 'em.

Last week we defined hard credit and soft credit. How does that look in Salesforce and the Nonprofit Success Pack (NPSP)? It all comes down to opportunity contact roles (OCRs). Opportunity Contact Role is a simple junction object that connects a contact to an opportunity. Besides the contact and the opp, there are two more fields: Role (a picklist) and Primary (a checkbox). In the original sales-focused use case of Salesforce, OCRs are used to designate the various people that you might need to talk to about a deal. You could check off one person as the “primary” contact on the deal and you could give everyone roles from a picklist, such as Influencer, Decision Maker, etc. NPSP uses OCRs in basically the same way, extending them a little further to control rollup fields for hard and soft credit. If someone has the opportunity contact role “Donor” then they are getting hard credit. There is an NPSP lookup field on opportunity called Primary Contact. Whoever is in that field will automatically be given an OCR of Donor (and Primary will be checked). You really don’t need to do very much to ensure that hard credit is assigned. If a contact is getting hard credit, the NPSP rollup fields for hard credit are getting values from this opportunity. That includes Total Gifts, Total Gifts This Year, etc. Most other OCRs confer soft credit. The specific OCRs that count toward soft credit in your org are set by your system admin , so it’s possible for someone to have an OCR on an opportunity and not have any credit (hard or soft) for that opp. But in general, if someone has an OCR connecting them to an opportunity other than Donor, they get soft credit. If a contact is getting soft credit, that shows up—You guessed it!—in the soft credit rollups. such as Soft Credit Total, Soft Credit This Year, etc. Remember our donations to Hudson Street Orphanage benefitting Annie and her cohort? Let’s look at a couple of those gifts: Oliver Warbucks gave $500 This is an opportunity on the Warbucks Household. Oliver is the primary contact and has the OCR “Donor.” Mrs. Warbucks has an OCR for Household Member that was automatically assigned. Shoe Fits Fund: $125 DAF gift on behalf of Goody Twoshoes This opportunity is on the Shoe Fits Fund account. Goody Twoshoes is the primary contact and gets a “Soft Credit” contact role. One more credit: Partial Soft Credit Since we understand soft credit from last week, let us now introduce the concept of Partial Soft Credit . Whereas last week I only ever talked about giving credit for a whole gift, partial soft credit is giving someone credit for only a portion of a larger gift. Here’s how it would work. Remember last week when both Oliver Warbucks and Goody Twoshoes both asked Mr. Munitions to donate to the Hudson Street Orphanage? Let’s say that each of them asked him to donate $75 to the orphanage, perhaps in honor of Little Orphan Annie’s birthday. When Mr. Munitions’ $150 check shows up, we could record partial soft credit for Oliver and Goody, each to the tune of $75, rather than giving them both full credit for having influenced the gift. Makes sense, right? And in that Trailhead module I linked to above, it's relatively easy to enter some partial soft credits in NPSP. But that’s a simple example with just two people to split the gift credit. I’ll be honest: Basically none of my clients (or former employers) use partial soft credits. The data nerd in me is sad about this. But it’s just rarely worth the effort when you get into things like… Three Bad Options: Workplace Giving The situations I find the most difficult to follow are third-party donation setups like payroll deductions or pass-through workplace giving platforms like United Way or Benevity. Remember the rubric: “Whose check is it?” The check comes from the workplace giving platform, United Way, or Benevity, or…) I think it’s pretty clear that we’re in a soft credit situation for the individual donors. The craziness comes in when you’re trying to figure out how to parcel out the soft credit (partial soft credit.) The moment the payroll deduction is made is the actual donation and the donation is to the workplace giving platform, not to your organization, hence a soft credit scenario. The problem arises when the workplace giving platform sends your organization one combined check and a list of the people at Company X whose contributions that represents. Some platforms send the detailed breakdown of how much was from each person, but not always. Some platforms tell you when the employees make their pledges, long before the payroll deductions start or the checks start coming, but you don’t get detail when the actual money arrives. And it’s my understanding that none of the workplace giving platforms actually go back and update you when things might change (like an employee that was doing a payroll deduction leaves the company mid way through the year.) This is where you really have to start asking yourself how much detail is worth your while. Imagine that you have a check from United Way and a list of 50 donors that went into it, with their individual amounts. The technically correct thing to do would be to create an opportunity on United Way account and then to assign partial soft credit to each of the donors. Of course, before you do that, each donor must be in Salesforce as a contact and there’s no way to predict if they already are or if they’re a new name. Then you have to assign the right amounts to each of them on the United Way gift. 🤯 Simpler would be to just assign each of the donors a soft credit contact role, giving them all soft credit for the full value of the gift. You still need each donor to be in Salesforce. And you’ve now done it “wrong,” in the sense that they’re each getting too much credit. But at least they get some kind of credit and you have a way to see the names of everyone that’s donated to you via workplace giving. 😕 The final option is to just record the United Way check and not give any soft credits. Nobody loves this option, but it’s dramatically less work. You have to make a decision for your organization about what you are going to do with soft credit information that would make it worthwhile to put in the up-front effort of all the data entry. 🤷‍♂️ Side Note About Keeping Data Clean: Corporate Donation/Payment on a Credit Card I want to call attention to one final scenario that’s really hard to deal with: Organizations using a credit card on your donation platform. If you’re a nonprofit that has some kind of earned-revenue situation, you might send out an invoice to a company. Depending on how that invoice was sent, it might not be payable by credit card. Or you could even have a case where a business notifies you that they’re going to make a grant/donation to your organization but they don’t do that kind of thing very often so they don’t have a clear process in place. In either of those situations you could have a well-meaning someone at the business who just pulls out their corporate credit card to pay the invoice or the pledge using the Donate Now link on your website. Ugh. The first thing to do is thank them for their desire to promptly get money into your hands. (The second thing to do is educate them about the realities of credit card fees and how much less money just got into your hands than if they had sent a check.) Don’t even mention to them that the donation link is not set up for organizational donations–it’s assuming this is an individual gift. Now it looks like a person made a personal donation but the money has actually come from an organization, not from their own bank account. And it’s also going to look like a sudden new donation even though somewhere else a similar amount is in accounts receivable, perhaps in Salesforce or perhaps in some other system… The technical term for this situation is A Mess . Realistically, you’re going to have to manually muck about with your database to sort things out. If we’re talking about Salesforce and a donation platform integration, there’s going to be an opportunity on the individual that should really be on the organization account. You could delete that, or modify it. There might also already be an opportunity on the organization account that was the one that’s really just been paid. You have to decide if you modify that one (to add the payment information) or use the newly created one (losing the history from the old one.) Like I said: a mess. PS: This has nothing to do with soft credit or hard credit. Once you get the information cleaned up, the soft/hard credit should be unchanged.

Third in a series. In part one I used a layer cake metaphor to explain licenses, profiles, and permission sets. Part two used Personas as the recipe for which users get which access and User Access Policies as the tools to execute the recipe. Now we talk actually getting it done! Disclaimer here: I have not invented anything new. At best I've synthesized smart ideas from others and translated them into the context of organizations the size and capacity of my small nonprofit clients. Hat tip in particular to Mike Reynolds who has been presenting on his persona-based framework for user access for years. And to many others from whom I've learned tips and tricks. Step 1: Define Profiles Remember: the profile is the bottom layer of your cake. We're working to get to a world where profile is used to set essentially one thing: defaults. Since a user can have just one profile, this is the place you are going to set things that can't be multiple, meaning default record types and, if you're using them, page layouts. The former are clearly required: for objects with record types, you need to set which willl be applied if none is selected or which will be offered as the default on the New Record screen. With Dynamic Forms you may have less need for Classic page layouts that get assigned by profile, but they still have their place. (I'm still using them in most cases.) Page layout assignment has to be at the profile level (1:1 with user) because it doesn't make sense that someone could see multiple page layouts. I am not working in environments where we have login IP ranges or those kinds of security settings that may also have to be applied at the profile level. Sidebar : I learned from one client that in Pardot (or Marketing Cloud Account Engagement, or whatever they're calling it these days...) you can only control some access based on the Salesforce user profile. So they have multiple profiles within a single team of Salesforce users. (Examples: Sales Team and Sales Team Tier II ) These profiles differ only in name . Each profile is minimum access and they have the same page layouts and defaults. But they have to exist to make things work on the Pardot side. Step 2: Build Permission Sets It feels almost redundant to mention it after two prior blog posts, but the first thing I have to get in order is my pile of permission sets. [Based on today's title I'm using the metaphor of how I do perms, so maybe that means "getting my scissors, chemicals, and tools ready next to the stylist chair." But I think the better metaphor here is that I bake my several thin cakes of complementary flavors and set them onto cooling racks.] In theory, for a simple org I could get away with having just a single "baseline" permission set. But in practice, particularly as I look toward getting all users onto minimum access profiles, I will need at least two that everyone is going to get: Baseline Permissions - This grants access to the objects and fields that everyone uses. Also includes the kinds of system permissions that everyone needs (Run Reports, Send Email through External Email Service, etc.). This permission set is not tied to a license type . See more below, but this permission set should generally only grant "CRU" permissions (Create, Read, Update). Standard Object Tabs - I actually put it right into the description of the permset why it exists: "Because the baseline permset is not limited to a license type it can't grant access to the standard object tabs. So this permset is used to do that." This permission set is set to License = Salesforce. All it does is set the tab to Visible for Account, Campaign, Contact, Case, Lead, Opportunity, Task, etc.) If I'm going to have integration users, they'll need a version of this permission set where License = Salesforce API Integration. If I'm going to have platform users, they'll need a version of this permission set where License = Salesforce Platform. In order to adhere to the principle of least priviledge , my baseline permission only gives the lowest common level of access my users need. That might mean it only gives View access to all objects, if I have a user that only should ever run reports. In the kinds of organizations I work with, everyone needs at least Create and Edit on most objects. But they don't need Delete! So when I'm being diligent, I keep Delete out of the baseline permission set. Then I have a Delete permission set for those few users that need it. (But I'll be honest and transparent: Sometimes the baseline permission set includes delete. I don't let the perfect be the enemy of the good. We are all on a journey toward perfect security.) Here's the start of the permission sets list view for one client: Of course, I start having more permission sets for other discrete areas of permission that only some people will need. This means things like access to a particular sensitive data field (Social Security Number) or a distinct piece of functionality that has its own objects and fields. The more complicated the org, the more permission sets there are going to be. If you get very large and complicated you might think permission set groups will help organize things. But I only work with small and medium organizations so I find permission set groups create more problems than they solve, as I noted in the first post of the series . One last quick note regarding permission set naming: You probably noticed in my list, above, that the permission sets for that org all start with "1DCPC." The org's initials, of course, are "DCPC" and that's the main thing that I try to do: start all my permission sets with the org's initials . That way they all sort together in alphabetical lists and it's easy to remember where in the alphabet to look. In this case I went one step further and added "1" so that they would all group at the very top of the list. That's even more convenient and I wish I'd done it all the time in all my client orgs! Step 3: Make A Persona Field As I said in the last post, personas are not an actual feature of Salesforce. I make my own Persona field. This is nothing more than a custom picklist field on the User object. I put that new field on the User page layout and make it required . [Yes, it annoys me that the User page layout isn't very customizable. I can only put the Persona field down "below the fold," so I often haven't filled it when I try to hit Save and then I'm prevented until I do so. Maybe—hopefully—someday Salseforce will give us the ability to really control user page layouts.] I create a picklist value for each persona for each license type . If you've been tracking carefully throughout this series ( and before ), you've got it in the back of your mind that users on different license types will need permissions assigned slightly differently, even if they end up with the same permissions in the end. So if you're in an environment with just one license type, then things are going to be simpler for you. But if you've got a mix of full users and platform users—as many of my clients do at this point—you have to account for the difference at the crust layer of the cake. I think it's pretty easy to choose among persona/license combos even though that makes for a longer list. The other option is to have just a persona, but then you'll have to distinguish, when assigning permissions, whether you're on license type A with that persona or license type B. I find that less convenient to actually accomplish. (More below.) If you're using this post to start retrofitting your org to do permissions this way, don't forget that once you create this field and set it as required on the page layout that only takes care of future new users. You also need to backfill this field for all current users. Sidebar : It would be an option to make yourself multiple profiles , one for each persona. If these were each minimum access profiles that are distinguished only by their name they essentially serve as your persona. But I don't love this option for two reasons: 1. Your org is going to have all sorts of extraneous profiles you can't get rid of, making it all too easy to choose a wrong profile. 2. By combining profile and persona you lose any potential ability to distinguish. (Giving some users the same persona but different page layouts for example.) Step 4: Create User Access Policies Now I create one user access policy to go with each of the Persona picklist values. The persona is used as the criteria for applying this user access policy (along with the user being Active, of course). If a user meets that criteria, they'll get the baseline permission set, the standard objects permission set, and any other permission sets that are needed for a user of that persona to do their work. (Since the user access policy can assign multiple permission sets, this is why I don't see a need for permission set groups.) And they'll be added to one or more public groups, which can be used to control things like report folder sharing. Last, but definitely not least, we are going to enable this user access policy and set it to run every time a user is created or edited. That will ensure that if you change a user's persona, they'll get the new permissions you expect to go with it. You can also click to apply the policy to existing users that meet the criteria. Now test your UAPs by creating and updating some users. UAP Gotchas: When you're setting up UAPs, you give them an order in which they will be evaluated. Once Salesforce finds one UAP whose criteria applies to a user, it stops evaluating the rest . This means you can't use them to incrementally build up permissions based on several different criteria that a user might meet. This is why I go with the persona field: it allows me to guarantee that the right UAP will apply. For this same reason, I don't really use the Order field on the UAP. It's supposed to allow me to control that one UAP will be found before another. But I'm already controlling for that with the profile field. As you might have noticed in the screenshot above, I just set them all to 1. I could just as easily set them to be sequential. With my persona field based rubric, it makes no difference. In a larger and more complicated org than I work with, I imagine User Access Policies is not a sophisticated enough feature to get everything done. In that case, I think Flow is probably the next best option. Step 5: Getting from Here to There The final element is to actually get to the setup I've just described from wherever the org has started off. (Hat tip Katie Villanueva  for asking about this on MVP Office Hours .) This framework is easy to implement if I'm starting from scratch. But I rarely get to start from scratch. I mostly inherit orgs with years of technical debt, little or no documentation, and sometimes everyone is a sysadmin. It can be a long process to give an org a stylish perm. That process might deserve a whole post of its own, but I'm not even sure I could give comprehensive guidance. Ultimately it's a lot of manual work that is very org-specific. Let me give at least an outline: I go through objects and reduce page layouts as much as I can. I figure out what is common and uncommon about page layouts assigned to one profile or another. In my experience, it's rarely worth having so many page layouts, they usually differ in only minor ways. It's frequently those different page layouts that actually are the reason for having multiple profiles. So as I consolidate page layouts, I find that that I can also be consolidating profiles. While I'm at it, I reduce record types, deactivating as many as possible. I absolultely get rid of Lightning Record Page assignments by app and profile. They're way too much to try to manage or compare. Conditional display can usually handle the kinds of things people might have made different by app or by profile and then, at least, I'm only working on the display in a single builder. I compare profiles to find how they differ regarding object and field access, default record types, things like that. In a small org, I can probably reduce down to just one or two. I try to look for any conditional visibility rules on Lightning record pages that might be based on profile. I learned recently, that if you use Dynamic Forms and have placed an individual field with conditional visibility it does not show up as a Where is this used?  entry for the field. So just know that dynamic forms are going to be a complication in this migration. All of this requires coordination with the users in the organization. Even if I've determined that page layouts all have the same fields on them, consolidating down to one probably means changing the order of at least a few fields for a few people, even if only in minor ways. They are entitled to some warning, at the very least. Once I've worked through all that I hopefully have a much smaller list of profiles than I started with. Sometimes I'm down to just one. Maybe three at the max. Then I make minimum access versions of each profile. For clarity, I give them the same name as the original profile, with "minimal" added. It will be clear to me later that those on "Program User" are going to move to "Program User - minimal." I can't decide whether it saves me time to clone the original and strip it down to minimum access or to start with a fresh profile (no access) and build it up to the minimum access that it needs. But either way, I should end up with a new profile that has default page layouts and record types that match the profile it came from, no object nor field access, and few, if any, app or system permissions. My general method for doing this is to open the original profile in a window to the left and the new one in a window to the right and click through each section comparing them side-by-side. This is tedious work. I don't think there's much way around that. With my minimum access profiles, my personas, my permission sets, and my user access policies ready, the last step is to test under real world conditions . That means that I'm going to have to find someone of each persona to be my first...victim. This needs to be someone that I have a relationship with, because I might make their job difficult for a day or two. I warn them that I'm going to switch them over and ask them to look for things that look different, stop working, or otherwise might be related to the change. I give them a direct line so we can fix things quickly. There are usually a few hiccups in the first day or two. After switching someone, I like to let them go for a few weeks before I'm ready to move everyone else of the same persona. This is a slow-and-steady process, but I get there eventually.

In part one of [what has become] a series, I used a layer cake metaphor to explain licenses, profiles, and permission sets. If I'm going to really embrace that metaphor ( And I am!) , then it's time to write about how to bake that cake. Personas are Recipes To torture my layer cake metaphor: Personas are the recipes for how we build out a user's permissions layer cake. Personas are not actually a technical feature of Salesforce. You can search the Setup tree all you want but—at least as of this writing— there is nothing there for "persona." Nonetheless, personas are a useful way to organize your thinking about what you need for each user. Product design—particularly software design—is often based around the personas of the different kinds of users that might interact with a product or service. Your Salesforce implementation is no different in that regard. Once you have figured out the personas that describe the different categories of work that people need to do, you know what combination of permissions they need. At their simplest, personas are one-to-one with job categories. Say you have: Executives - Mostly look at reports and dashboards. Fundraising Users - Enter opportunities and payments, update contact information and relationships, etc. Program Users - Enter program contacts, update program records, etc. (Of course, if you have many programs you could have different personas for each. But we're keeping our example simple right now.) System Administrators - Have access to the whole system and Setup. Each of these personas need their own recipes to end up with the right layers. Cross functional jobs probably constitute their own persona, but you can already see that their access will just combine the two functions that they cross. They get an additional layer of the cake. Note that Persona, the way I'm using it, is like profiles were in the bad old (and often current) days of user management in Salesforce. So you may have a bit of persona proliferation to delineate similar roles or users with the same role on different licenses, etc. Even if you end up with a lot of personas, we are still facilitating you moving to all profiles  that are minimum access. You'll see that it's going to be easier to maintain several personas than it was to maintain several profiles. Your user personas tell you the recipe for the cake you're going to bake. Now into the kitchen! User Access Policies Are...The Kitchen? [ It's official: My metaphor has gotten out of hand. ] In Summer '24, Salesforce released User Access Policies . This is a handy and fully declarative Setup tool that allows you to automate granting or revoking of permission sets to users or adding users to public groups. User Access Policies are a major step toward making it easy enough for admins to get to the permissions-off-profiles future. So let's think of User Access Policies as the kitchen, including mixing bowls, layer cake pans, stand mixer, oven, etc. With access to a kitchen, you can turn a bunch of ingredients into a delicious multi-layered showstopper of a cake. With User Access Policies we can turn our list of personas into a fully functioning user management regime in short order. No more maintaining (usually somewhere outside of Salesforce) a flow chart of what to do when you are creating a new user. You turn that chart into User Access Policies and the work should be done—or at least mostly done—for you by the robots. That's the subject of my next post. I don't think it's necessary for me to actually write up a How To guide for using User Access Policies. There's a Trailhead module for that .

Once upon a time, user permissions ("perms") were controlled by user profiles. Then in 2023, Salesforce announced, via a blog post from Cheryl Feldman , the "end of life" (EOL) of permissions on profiles. Eventually profiles will be stripped nearly bald and all permissions will be assigned by permission sets. All that will be left on profiles will be those settings or permissions that are 1:1 with a user, like the default app, default record type, page layout assignment, login hours, and a handful of other things. Everything else, including settings like Edit Reports, or object and field access will be assigned as part of a permission set (or "permset"). It's a couple years later and I'm not sure we're really any closer to that future from a technical standpoint. That blog post has been updated a few times to indicate that the EOL for permissions on profiles is not on the horizon. But it's been clear for a while that the future of user permissions is going to be one of very basic profiles and a lot of permission sets. So it's time for admins to start thinking more about their perms. It's time to start thinking about how you will eventually move your organization into the permission set-forward future. Apparently this is about to be a short series of blog posts. Today we start with the basics of understanding user access. Permissions as a Layer Cake To switch visual puns and metaphors, I like to think of permissions as a layer cake. The future of user management is all about layering on the right access for each user. User License We start with a base that everyone needs, which is the user license. (Without a license available, you're not going to be creating a new user. Whether platform users , community users, API-only integration users , or full Salesforce licenses, everyone that logs into Salesforce is doing so based on a user license.) For today's discussion, we don't need to put too much time into license type. But it's definitely there, like the bottom crust. Profile As I mentioned above, the profile is 1:1 with a user—you can't have a user without them having a profile. That makes profile the second layer of our cake. (To be honest, I usually think of profile as the first layer.) In most orgs today, Profile is the true heart of your user setup. You probably have a profile that corresponds to each of your departments. You may have more granularity than that, with regular users and power users within each department. But that's often all there is. And once you've assigned a profile, that might be it. The profile contains all the app permissions, object CRUD (create/read/update/delete), and field level security the user needs to do their job, so they don't routinely get any permission sets. If this is your org at the moment, don't feel bad. This was "the way" for a long time. As long as you have a couple of profiles, rather than everyone being a sysadmin, you're ahead of a lot of orgs. (Please do not do that!) If your org's user access is just license and profile, that's just two layers. I guess you have a user access pie. Pie is delicious, so I can't fault you. It's Salesforce's/Cheryl's plan that eventually there won't be a whole lot of substance to the profile. It can't go away—you need something to hold those 1:1 settings. It's just going to grant a whole lot fewer powers than it does today. So eventually, just having profiles is not going to be enough. Permission Sets In the layer cake future, all the power is going to come from permission sets, piled onto your base profile. Each layer has its own flavor and texture—which, in our metaphor, means that they each grant different permissions and they build on each other. When I'm planning permissions, I usually start with a "baseline" permission set that I'm planning to assign to every user. This permset is going to grant access to the shared common set of objects and fields that everyone needs to access. This means Account and Contact, for sure, plus any custom objects that are at the heart of your org's Salesforce usage. Depending on the org, not all users may need to see Opportunities. But I definitely put some of the NPSP objects in my baseline permission set as well, such as Relationships. And I put baseline system permissions in here as well, such as Run Reports, Schedule Dashboards, or Chatter Internal User . Let me be clear: this is not the only way to do this. I tend to work with smaller clients and we are prioritizing simplicity. Your needs may vary. Or you may have fewer settings and objects truly in common for all your users. There's no requirement for a single baseline permission set. I just find it simpler to work with. (And I do not want to use permission set groups, for reasons I'll explain below.) In some small/simple orgs I manage to have basically only this one baseline permset. I Don't Love Permission Set Groups I would be remiss if I didn't mention permission set groups ("PSGs", or "permsetgroups") in this discussion. But I'm only going to touch on them briefly because I don't like them and I mostly don't use them. As their name implies, permission set groups are a way to bundle a bunch of permission sets together. Then you only need to assign the PSG and the user gets the access of all the permsets inside. Permsetgroups have one nifty feature: muting permission sets. Within a permsetgroup you can create a muting permission set that turns off permissions that reside in the underlying permsets. Note that a muting permission set only applies within the permsetgroup . So if a permission set outside the group or a second permission set group grants a permission that's muted in the first one, the muting doesn't apply. To me, it's not that much less work to use muting than to make permsets with fewer permissions and then give a Super User permset to add power. And it's less confusing. The other downside that keeps me away from permission set groups is that they have to recalculate any time there is a change to one of the permission sets within them. Every so often I need to open the permissions for a few objects in tabs and make changes to each. But if those object permissions are within a permission set group, each save has to finish calculating before I can hit Save on the next. It usually takes a full minute between saves. That's very annoying. But even more frustrating is that a permission set group can fail its recalculation silently! If you happen to be on the PSG list view, there is a Status field but it's not that likely that you're going to sit there waiting to see that it shows Updated. And you don't get any email notification that your permission set change led to a failure in the permission set group recalculation. Last: it's just not that much harder to assign several permission sets than it is to assign a group. And by using only permission sets you only have one place on the user that you need to investigate when you're trying to figure out their user access picture. And there are ways to make assigning the right permission sets easy, so I think groups aren't that neccessary.

Lately we've been talking about Salesforce platform licenses , which are a great way to bring more parts of your organization onto Salesforce without big expense. But I don't want to pretend that the Salesforce admin setting up platform users won't run into some challenges here and there. Whether you manage your permissions primarily on profiles or have moved into the " future of user access , " with almost everything provided by permission set, you'll have to think about platform users slightly differently than full users. Basic Profile Right from the get-go, when you go to set up your platform user, you'll find that you can't assign the profiles you've already been using because each user profile is tied to a user license type. So whether you're using the Standard User profile, one of the NPSP-installed profiles or a custom profile for your organization, you'll need to use a different one. (You will get a new Standard Platform User profile if you want to use that as a starting point.) If you try to create a completely new profile, you actually have to start by cloning an existing profile, which also clones the user license of that original. So you're not going to get around this. Basically you're going to have to have a different profile for any users on platform as opposed to full licenses (just listed as "Salesforce"). That's not a big deal, but it does mean you have at least one more thing to manage. And whenever you make a change that is going to affect profiles (like setting default record types or app access) you'll need to make the change for at least two profiles, not just one. (Realistically, your minimum is probably three, since you should have at the very least yourself on System Administrator and everyone else not on System Administrator.) Basic Permissions When it comes to assigning the rest of the permissions your users are going to need, I'm going to talk about this for orgs that have moved to put all permissions on permission sets. (A full discussion about moving from profiles to permission sets will be another blog post...someday.) If you're managing permissions still on profiles, then you're already managing your platform user profile differently from your other profiles. I tend to keep a single baseline permission set that will be assigned to all users. The idea here is that this single permission set grants access to all the apps, objects, fields, and abilities that every user will need to work within the organization. But since platform users can't access Opportunities or Campaigns, a baseline permission set meant for all users is going to have to leave off access to those two objects. (If you tried to assign a permset to platform users that granted access to Opportunities or Campaigns, it would error.) So right off the bat, if you have some platform users you're probably going to need to break out the true base line permissions and put additional permissions for full users into a second permset. In addition, don't forget that Platform Starter users are supposed to only access ten custom objects. So keep the object count in mind as you build up the truly baseline permission set. Other Special Permissions The other things you'll find, depending on how your baseline permission set was built, is that it might have various special permissions in it that can't be assigned to platform users. I don't have a list handy of what those might be, but various things that might be checked off under System Permissions in the permission set. There are screens and screens worth of items in there. It's actually kinda' hard to understand what some of them do. And some of them are permissions you can't give to platform users. So when you go to assign your baseline permission set to a platform user, you may find that you have to uncheck something. Maybe it's something that you can tell shouldn't have been granted to users in general, in which case you can just remove it. But this might be another area that forces you to have two baseline permission sets, one for platform users and one for full users. Access to Cases Unlike Opportunities and Campaigns, which they can't access at all, platform users can see the Case object. But you may need to jump through some additional hoops to grant them access. (Because: Salesforce.) I was working with a client recently to reduce their license cost by moving a bunch of their users to platform licenses. When I tried to assign them our basic permission set I got an error that prevented it from being assigned to platform users because it included access to Case. I'll be honest: I had a moment of panic, and started questioning whether our license strategy would work if we couldn't give Case access to a whole department. But I was sure I'd had platform users in other clients with access to Case and the documentation about platform users never mentions a restriction around Case the way it does for Opportunities and Campaigns. Luckily, this blog post showed that you can create a license-type-specific permission set that will allow access to Case for platform users. It's one more permission set to manage, but it gets the job done. Annoying. And I'm almost certain that in other client orgs I haven't had to go to this length to give platform users access to Case. 🤷🏻