Search Results

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. 🤷🏻

It's funny, I've written about platform events several times ( here and here and here ), but I seem to have barely mentioned platform users (only here ). Time to rectify that! Clarification Once I started writing, I realized I could be creating some confusion. So: Platform events and platform users are two totally different things , completely unrelated. They are united only  by having the word "platform" in their names. What are Platform Licenses? Platform Licenses are the user licenses you can purchase if you truly do not need a user to access Sales Cloud or Service Cloud features. As their name implies, they grant access to the Salesforce platform but not to Sales Cloud nor Service Cloud. If you thought that sounded like a non-answer, because you don't even think of Sales Cloud or Service Cloud as separate from the platform, you are not alone. For reasons that I think have mainly to do with company history (and technical debt), the products that we usually think of as a generic "Salesforce license" are actually Sales Cloud licenses. These allow full access to the Salesforce platform as well as access to some things that Salesforce considers part Sales Cloud (Opportunities, Campaigns), even if we usually just consider them a standard part of the platform. Service Cloud licenses, similarly, are 99% about access to the platform, though purchasing a Service Cloud license also comes with some Service Cloud features (like Knowledge and Entitlements). Particularly in the nonprofit world, where the P10 grant of free licenses gives Sales+Service licenses, we rarely consider whether there is a difference between one "user license" and another. [I've written about making sure that when a nonprofit purchases their 11th and later licenses they should only pay for Sales Cloud licenses , because they don't need Sales+Service.] All that is to say that, other than in the context of certifications, in my experience most Salesforce professionals barely even think about Sales Cloud as a somehow different "product" than Service Cloud. We know, intellectually, that the Case object is part of Service Cloud—and are reminded of if when we have to go to Setup>Feature Settings>Service>Case Assignment Rules—but it rarely matters. Salesforce doesn't help make the distinction clear either. If you go to Setup>Company Information>User Licenses, your Sales Cloud, Service Cloud, or Sales+Service licenses all show as just "Salesforce" while your platform licenses are on a line marked "Salesforce Platform." Because of this (and to make myself part of the problem), I usually refer to Sales or Service Cloud licenses as "full licenses" to distinguish them from "platform licenses." In practice, users on platform licenses are just another user. They can log into the system, can create and edit records, view reports and dashboards, trigger the firing of automation, run screen flows, etc. Because those users don't have Sales Cloud or Service Cloud there are some standard objects they can't access (including Opportunities and Campaigns). But there are a lot more that they can access. And they can access custom objects that you have created or that are part of managed packages (such as NPSP or PMM ). To add a bit more complexity, platform licenses also come in two levels, Platform Starter and Platform Plus. Besides a difference in price, the distinction between those two is that Starter are only allowed to access ten custom objects, where Plus can access up to 110. Both of those counts are of your org's custom objects. Objects installed by managed packages do not count against this limit. (And as I noted when I wrote about stacking , it's possible to give access to more than ten objects for platform Starter users.) One last distinction to think about for platform licenses: You will need different profiles and may need different permission sets to go with platform licenses. Most of the time you can work with platform users exactly the same as other users on full licenses. But every so often you'll find some place where you need to work slightly differently for them. For example, if you have a baseline permission set that grants access to all the objects and fields your organization users have in common and it includes Campaigns, you won't be able to use that permset for platform users (because they can't access Campaigns). Usage So how do I use platform licenses with my clients? They're a way to save money! Depending on what your users need to do and how you have designed your Salesforce system, platform licenses may be a great way to get more people on Salesforce without breaking the bank. You just have to think about (and design around) the limitations. Since platform users can't access Opportunities (nor, by extension, any objects that are child to Opportunities, like the NPSP Payments object), you probably can't use platform licenses for anyone that works in fundraising and development. Since they can't access Campaigns, you will have to have platform users doing their job without using Campaign List Emails. But the many objects in the Program Management Module (PMM) come from a managed package, so they are all available to your platform users. And if you've designed a program management setup in Salesforce that just relies on Contact, Account, and a handful of custom objects, you're good to go! For example, I've worked with clients that serve students around college acceptance. They track students (contacts), schools (accounts), programs (custom object), enrollments (custom object), college entrance tests (custom object), and college applications (custom object), as well as a few other things. It's no problem for program staff to use platform licenses. Pricing As you've probably guessed, platform licenses are quite a bit cheaper than full licenses . Full Login:           List price $1,980/year (Nonprofit: $495/year) Platform Starter:         List price $300/year (Nonprofit: $72/year) Platform Plus:          List price $1,200/year (Nonprofit: $288/year) That makes platform starter 85% off!   The savings are less dramatic for nonprofits, who are already getting a steep discount off list prices. So if your nonprofit only has a few users above the P10 grant, it might not be worth the admin overhead (or, let's face it: technical debt) to support the second license type. But the cost/benefit catches up once you're paying for ten or more users that could be on platform—particularly if they could be on Starter. The Crowdsourced Pricing Guide (User Logins tab) is probably the best place to look for the full pricing details, by the way. Only Platform Users? I should note that you can't have an org entirely on platform licenses , as far as I know. You have to have at least one full license as a system administrator. This wouldn't be a concern for a nonprofit that's going to get the Power of Us license grant, of course. But for everyone else (including nonprofits that are building a second Salesforce instance) it's way cheaper to have one or two full licenses for sysadmins and then all the rest be platform users.

Just after I wrote my post about using Platform licenses , I got an email from a reader asking about the idea of using platform licenses with Nonprofit Cloud (NPC). The funny thing is that I had considered whether or not to mention NPC when I was writing, but, in the end, decided that it would just add confusion and length without helping people. I'm going to leave aside the question of whether an organization should be using NPC in the first place. (I think I've written enough about that elsewhere .) The real questions are whether platform users are compatible with NPC (or any Industries solution like Public Sector Cloud, Health Cloud, Education Cloud, Manufacturing Cloud, Financial Services Cloud, etc.) and how the costs would work . By the way, I'm going to just write "NPC" for the rest of this post. But as I understand it, what I'm writing would apply to any of the industry clouds. For any platform user that was going to touch any of the NPC objects (“standard” objects...but not really ), you would have to have a permission set license (PSL) to assign to that user. When you buy "one more user" for nonprofit cloud, you actually get a license (user login) and a PSL, bundled together. I do not know if you could get an AE to sell you PSLs separately from full licenses. And if you could get them to sell one, what would they charge? It might be that they’d charge nearly as much for only a PSL as they were offering to charge for a full license + PSL. Now You See It Regardless, without a PSL assigned, even a full user can’t see the Industries objects. So any user that was going to “use Nonprofit Cloud,” in the sense of actually seeing any of the objects or fields that are part of that offering, will need a PSL. This will reduce your pool of PSLs compared to your pool of full user licenses. And keep in mind that “part of Nonprofit Cloud” also means the Industries-based program management offering, outcomes measurement, the upcoming volunteer management functions, etc. I suspect that there’s probably no technical reason you couldn't assign a PSL to a platform license—it seems about the same as assigning one to an integration user. I can't test this assumption, however, because I don't currently have any clients on Nonprofit Cloud, much less any that also have a platform user. Let me also note that currently, if you assign a PSL to an integration user, you already find yourself one short for assigning to humans. I asked about this problem at True to the Core during Dreamforce 2024 (and the same problem that applies to the Marketing User checkbox). I've been promised that a fix is coming, but not very soon. Maybe Users Don't Need to See It Of course, if you have an NPC org and some users that are going to do things that are not within the Industries objects , you should be able to use platform licenses to your heart’s content. Even if your configuration involves person accounts (due to that being a required part of NPC), platform users can handle it. (I set up a client with platform licenses and a person account setup before NPC even existed.) I don't know if platform users could see Industries components on your page layouts (like Timeline, Interaction Summaries, or R2D2s). But maybe you just wouldn't use those components . Plenty of non-Industries Salesforce instances get along just fine without those components. Or they use AppExchange options that work as well or better. (I'm looking at you, Timeline .) Money on the Line If you are a wealthy or large enough organization to be considering NPC (or any other Industries product), then you've already made the choice that most of your user licenses are quite expensive ($720/year for NPC, much more for the for-profit offerings). Trying to save money by putting some users on platform licenses seems like it might not be the right question. And, of course, I've argued more than once that small organizations are not a good fit for NPC (or other Industry clouds). So in that case it seems not really worth asking whether you can use platform licenses with NPC...

Today I'm writing to introduce a cool and useful tool that my son, Arden , developed. I'm actually rather late in writing about this—Arden made this for me over a year ago. (In case the IP Police are listening, IceTea was developed long before Arden even applied for his current job. So don't click on his LinkedIn and assume it has anything to do with where he's working now that he's graduated college.) Despite too much delay, I hereby present: IceTea . What Is IceTea? IceTea is a little utility that does two things: Open a database (stored as a .sql text file in your CumulusCI repo) in Excel. Convert that Excel file back to .sql after you've made changes to the rows. What is so delicious about it? When you store a dataset using CumulusCI it takes the form of a SQL database in a text file. Though it's theoretically possible to hand-edit if you need to change a value in that table, it's rather inconvenient. And if you want to add values for blank fields (represented by ". '', " in the table), good luck getting the right place! Using IceTea, though, you can look at that same table in Excel: Now it's easy to see who needs a Title and to add Descriptions to the right people. Where can I get some? IceTea needs to be installed on your computer, not into Salesforce. Just go to IceTea's GitHub repository and follow the instructions. ** Disclaimer: Only install the IceTea software package to your computer. Do not bring iced tea or any other liquid into contact with your keyboard or any other part of your computer. Such actions usually result in undesired outcomes . [Our lawyers insisted that we write this.] What Else do I need? IceTea was developed for use with CumulusCI (or CCI, for short). You pretty much have to be using CCI for IceTea to be helpful to you. CCI is a development tool originally created by Salesforce.org to make it easier to develop NPSP and the other nonprofit packages. I'm gonna be honest and admit that I don't really know who is maintaining CCI at this point or how much love it's getting. As I've said many times: I'm not a developer . I'm not using CCI for any of its features around managing GitHub repos, automating testing, or the like. I use CCI because it has one particular superpower that I haven't been able to get anywhere else: It can automate storing and inserting a dataset into a Salesforce org, keeping relationships between records intact . That's super powerful (and probably deserves its own blog post)! By storing a dataset for a client in CCI, I can create a sandbox and then put in a set of representative data, including contacts, their accounts, opportunities (donations), and any other custom objects I need. The biggest frustration I hear from admins talking about not building in Production is that when you create a sandbox it has no data in it. It's hard to test a new flow if you don't have a record for it to fire on. And if your org is at all mature, getting data that looks like reality means filling a lot of fields and creating an interlinked set of records to represent, say, a class, the enrolled students, the dates on which the class meets, etc. Using CCI you generate a mapping of your org's custom objects and fields, download the data that's in your org (please do this from a sandbox, not production!), store it, and push it into another sandbox with all the relationships intact. For free! Working with a command line tool has been a learning curve for me, but it's incredibly helpful. How do I use IceTea? Once you have the prerequisites out of the way (a CCI repo, with a dataset file), there are just three steps (two commands): icetea in - Running this command will take your dataset.sql file (like the dark screenshot, above) and open it in an Excel worksheet. Each object will be in its own tab. Make the modifications you need. Do not mess with the header cells of the sheets, as Arden has done some special work there to store information he needs in the conversion. It's safe to reorder columns and tabs for human convenience. And the real point is to update the data. So, for example, you could take a downloaded dataset where no contacts have a Birthdate and add dates for everyone. Or take a bunch of emails and replace them with ".invalid" or the like. icetea out - This command will convert your sheet back to dataset.sql and delete the temporary Excel file. Simple and satisfying, just like a nice glass of iced tea!

Every time I teach a new user about Salesforce I cringe when I get to the point of showing them the Reports tab. On the one hand reports and dashboards are one of Salesforce's great strengths . Free and out of the box you get instant ability to pull out the data in your system, slice, dice, and visually display, and more. (Unless you're trying to report on the NPC data model . But that's a different issue.) Unlike lots of other systems, Salesforce is not limited to a handful of canned reports and at the mercy of your platform provider to build new or custom reports. That's super powerful! But after giving a tour of record pages, relationships, and data entry, when I direct the user to click on the Reports tab I suddenly have a different user interface. Unlike all the other object tabs, where I can show users how to change the default list view that loads and pin their favorite, Reports always loads to Recently Viewed. Plus the navigation is via links on the left side. And there are folders to navigate... Not that any of this is particularly difficult, of course. I suspect everyone reading this blog is so used to it at this point that you barely notice. But inconsistency doesn't do anyone any favors when learning the platform. And can I just state for the record how annoying it is that there is no New button under the Reports tab carat, like there is for all object tabs? Having to click to the reports tab before clicking New Report has to be one of the biggest time wastes in all of Salesforce. Several releases ago Salesforce came out with Analytics Home . As is the company's pattern, they made a small publicity push at the time but it's basically fallen off the radar. In some recent conversations I was reminded of the page and wondered if there was cause to give it another look? Still Inconsistent The first thing you notice if you go to the Analytics tab is that, if anything, it's more different than the Reports tab is, not less! I assume part of the reason for this is due to this page combining the Reports tab and the Dashboard tab, hence the Create button, instead of a New button. That, at least, isn't such a big deal, so I can cut Salesforce some slack. (But honestly, wouldn't three buttons have been better?) Other than that, my first impression is that Analytics is not that dissimilar from the Reports tab or the Dashboards tab. Navigation is on the left, there are no customizable list views, and it basically defaults to Recently Viewed. There are some large cards that take a chunk of screen real estate. (It's debatable whether the tradeoff there saves time or clicks.) So far, this feels like "a distinction without a difference," as one of my high school teachers used to say. Slightly different interface compared to Reports (and Dashboards). "Two tabs for the price of one," I suppose. Still inconsistent with the rest of Salesforce. At best, I'd say it's debatable whether this is an upgrade. And those of you who know me should already anticipate two things I'm really disappointed by: There is still no option to start a new report from the tab header. It actually takes one more click to make a new report than it did before. (Analytics tab. Then then Create. Then New Report.) Now the Bad News But now let's get into the things you only notice if you try to use this "feature." Items Don't Load to URLs The section title kinda' says it all. When you go to a report from the Analytics tab you somehow remain at the same URL! https://yourcustomdomain.lightning.force.com/lightning/page/analytics Most of the time, this probably doesn't matter. But as soon as you want to grab a link to the report so you can send it to someone, you're out of luck. OK, not entirely out of luck. There is a new Share button if you've loaded a report from here. With that button (and one more click ) you can copy the URL for this report. But that's yet another difference from the normal interface where we've taught our users to grab the URL for sharing. By the way: The Share button doesn't give the regular report URL—it's about tthree times as long. Clicking on that special link ensures that you load the report as though you'd come from Analytics Home. This feels like a step backwards. No Chatter! Last post I wrote about using Chatter on Reports and Dashboards . Look at that last screenshot. It has no Collaborate button! As I noted in that prior post, I know Chatter's days are numbered, eventually to be replaced by Slack. But are we supposed to conclude that if you get there from the Analytics tab for some reason collaborating on reports and dashboards isn't a thing? Surely it is. So how are you supposed to give context for which report or dashboard you’re working on? And why wouldn't we want to collaborate right on the report itself? "Navigation breadcrumbs" The official Help docs on Analytics Home excitedly point out that, "Navigation breadcrumbs are activated when you open a report or dashboard." That sounds nice. But those breadcrumbs just give you a link back to Analytics Home: Home > Lightning Report It doesn't list the folder. Doesn't give the report's name. Presumably the Analytics tab is part of your app navigation in the first place! Honestly, if you can't tell whether you're in a report, a folder, or a dashboard at a glance, the navigation breadcrumbs aren't going to help orient you that much. Oh Well I don't know what else to say. I see no point in the new Analytics Home.

I bet a lot of you didn't know that you could turn on Chatter for reports and dashboards. This is one of my favorite quick little tips. You can enable it with just a couple of clicks and then you instantly gain the ability to collaborate right in context about reports ("Does this have all the columns you need?") or dashboards ("Take a look at the Dashboard of Zeros, we have some data that needs cleanup!"). Shall I give you the step-by-step instructions? Step One: Enable Feed Tracking Go to Setup>Chatter>Feed Tracking and then select the Dashboard object. Click the Enable Feed Tracking checkbox and then Save. (Repeat for the Reports object.) That's it. There was just one step. Using Chatter on Reports and Dashboards Now that you've enabled it, simply go to a report or a dashboard—you may need to refresh your page—and you'll have a button that wasn't there before: a "conversation" icon. (It's subtle, but those are two speech balloons.) Click that button and a Chatter pane opens from the right-hand side. Now you can post an update, @mention one of your colleagues, or respond to conversation right in context. This is also a great way for one of your colleagues to ask if they have questions about a report. Anyone they @mention will get a notification with a link directly to the report being asked about. It doesn't get a much easier than that! [Update 7/7/2025- Hat top to Julie Arnzen for the note that you may need to adjust your Global Publisher layout to make sure it has Post on it. Otherwise you'll get the Chatter pane but without the ability to write a post.] My Favorite Thing Truly my favorite thing about using Chatter on reports and dashboards is that it removes a lot of the back-and-forth when someone asks about something that seems obvious to them but isn't to me. Like an email that says, "The dashboard looks like it needs updating." For the person that just sent me that email, it seems obvious which dashboard they are talking about. Perhaps, as far as they're concerned, their organization has only a single dashboard, or at least only one that gets used regularly. But I don't have much confidence in my ability to be sure which dashboard that might be. So I have to write back to ask. At that point they're likely to just give me a name, not even a link to the right dashboard. Names aren't always as unique as people think. So I still have to search around to be sure I'm answering what they are actually asking. But if I get a Chatter question about a dashboard, I know exactly which one they mean. It's like an Easy Button to start the conversation. [With a conversation about a dashboard, there are plenty of opportunities for confusion about which component and which underlying report they have questions about. But at least we've narrowed the focus...] Also Useful in Other Places I think Chatter is a very cool feature—and often underutilized. If you teach your users about it (plus enable it and put it on page layouts) Chatter is a great way to collaborate within Salesforce. And just like I mentioned above, it saves a lot of time figuring out which records people are talking about. So much better than copying the URL to send an email about a record! Side Notes Two things before closing out today: Chatter might not last forever. Salesforce doesn't seem to care that much about Chatter anymore, particularly since their acquisition of Slack. In fact, Parker Harris has said, half- (or less) jokingly, that he intends to kill Chatter . As with other Salesforce retirements/deprecations, I expect this will be a very very slow death. But I wanted to acknowledge this fact. If/when Chatter is entirely replaced by Slack I have no idea how this kind of collaboration will change. And if your organization doesn't use Slack, I can't speculate what that would mean in your situation. Make Sure Email Notifications Work! In the Winter '24 release Salesforce made a change that required you to take action to ensure that notification emails about Chatter posts are sent. This flew under the radar for a lot of people, so you want to make sure that it's set properly in your org (or all of your client's orgs). If you start trying to collaborate on reports and dashboards using Chatter and the only notification people get is on the little bell in Salesforce upper-right toolbar you're going to have rather one-sided conversations!