Search Results

I bet some of you have been wondering why I hate new Nonprofit Cloud (NPC). I'm not sure anyone has ever asked me directly with exactly this wording of the question, but I've definitely had people ask me a question in the same genre. No doubt I've written pretty harshly about NPC, directly, in the Emperor's New Clouds , and less directly, in posts on extension objects , person accounts , and even Salesforce's business strategy . I tend to be pretty transparent about what I think. But I don't hate Nonprofit Cloud. I mostly don't care about it. I don't think it's a product/service/offering that is going to affect my business or the day-to-day operations of my clients, small nonprofits. A Car Analogy I'm reaching for a car analogy to make this clear: I have about as much interest in Nonprofit Cloud as I have in Maclarens. That is to say, very little. For my whole life, my family has owned relatively practical and affordable vehicles. Toyota Camrys, Honda Civics and Accords... Not the absolute cheapest on the market, for sure, but not much in the way of vehicular splurges. [Sure, there has been some fun in the mix. My first car was a sweet 1967 Olds 442 convertible that my uncle loaned me long-term. And I bought a Celica convertible in my twenties that I drove until taking my mom's hand-me-down beige 1998 Toyota Camry in 2006 to fit two kids. I drove that one until 2022 (and my children are still driving it). Two years ago I bought a Polestar 2 electric vehicle. That was pricey, but I paid the extra for the sake of the environment.] To go back to the analogy: The cars I drove are ones most Americans would be pretty familiar with. If I think about "the car market," I'm thinking about regular vehicles. I may hate the fact that Americans drive large trucks and SUVs, paying extra and keeping fuel economy down. And I don't love that when I go to purchase a car there are fewer sedan options and fewer good fuel economy options than there should be. But that is the extent of how much I think about "the car market." When my son brings up things like Maclarens, Bentleys, even Porsches, I don't have any interest. Luxury and super luxury cars just aren't something I think about. I'd probably feel differently about Maclarens if there was some kind of program subsidizing them for low income car buyers. ( Then I'd be incensed that people were being handed a car that was going to bankrupt them in fuel and maintenance costs.) How I Feel About NPC How I feel about luxury cars is how I feel about NPC: It just isn't relevant to me. When I think and talk about "the Salesforce ecosystem" or "the Salesforce platform" I'm considering the features and functions that most organizations use. Anything behind the Industries barrier is too niche or too expensive for any of my clients and for the majority of other admins and users out there. You Can Feel How You Want I've also gotten pushback from consultants that are working with NPC. They let me know I'm too harsh or too negative and that they're using it with their clients. That's fine. To be clear, those are two very different assertions: If I'm too harsh or too negative, I'm open to hearing the ways in which my analysis of the features or functions is wrong. For the most part, other consultants have not pushed back on those things. In fact, they pretty much all tell me I'm spot on. And of course there are consultants using Nonprofit Cloud for their clients. But those are much larger clients than I have, larger than 90% of the market. I've said repeatedly that this might be viable for large organizations. I don't think I've heard from anyone that they're implementing for a small or medium client and finding that it makes sense. They may be doing it, but they're having to build workarounds and figure things out in all the ways that I've pointed at. Can it be done? I'm sure it can. Will it be expensive? Yes. Will the client be happy and use the system long term, recommending it to their peers? Only time will tell.

Once upon a time it was relatively easy for a small nonprofit to self-implement Salesforce. It's how I got started , and many other nonprofit Salesforce professionals as well. We were working at a small organization, we needed CRM, and "this Salesforce thing" seemed like it could work for us. We spun up a trial org, applied to the Power of Us program , spent some time playing in Setup, possibly spent a couple thousand dollars on a "quick start" with a consulting partner, and we were off and running. The quick start consulting engagement was optional, but, at least in our case, it gave us a boost and some confidence that I was getting things right. Once Trailhead launched in 2014 it became even easier to self implement because that is one amazing free (and fun!) learning resource . Naturally, success on the platform varies. And the quality or scope of an in-house DIY implementation is going to be a lot different than you would get from a big partner project. But for basic fundraising tracking needs and an upgrade from spreadsheets, the Nonprofit Success Pack (NPSP) is pretty great for the needs of thousands of organizations. And as your in-house person grows their skills, it's easy to grow your Salesforce to support more and more of the business needs.  ⚠️ Self Implementation: Would Not Recommend ⚠️ But in 2024 I don't think I would recommend that a nonprofit self-implement Salesforce. It's become much more challenging than it used to be. I won't say it's impossible because I believe that a motivated person nonprofit staffer with some level of technical comfort (not yet "expertise," but a willingness to try things, learn, and dive in) could do this on her own. With time to devote to the project, engagement with Trailhead and the help documentation, and a willingness to engage with the community and ask questions, a newcomer could implement a credible NPSP setup for their organization. Of course, the organization would have to allow that staff member to devote time and energy to the implementation. It's the amount of time required that has gone up significantly. Full Disclosure (if you didn't already know): I make my living implementing and supporting Salesforce for small nonprofits. Clearly that means I have a bias toward someone hiring a consultant for an implementation rather than doing it themself. So take my comments/opinions here with that in mind. But I'll give the reasons for my thoughts and let you decide. That Was Then What I remember of our Quick Start in late 2012/early 2013: We got 40 hours of consultant time for a prepackaged implementation with minimal customization. The "quick" part meant that customization was limited, but we also got something of a discount, or at least a fixed price. I remember it costing $5,000 or $6,000. (40 hours at $150/hr sounds about right.) That was 12 years ago and inflation is real. But I don't think too many consultancies are offering a basic implementation even for the inflation-adjusted equivalent of about $8,000. The Salesforce platform has evolved, of course, with more powerful automation through Flow and new products and services that organizations may need advice about. An organization probably has more acute questions when starting their Salesforce journey, as I'll talk about below. And it's just a different landscape with nonprofits served by the Industries vertical within Salesforce rather than a nominally-independent Salesforce.org. All that is to say that I am clear-eyed about how organizations will relate differently to their implementation partner than they might have back then. A small org that just "wants to start using Salesforce" may actually need more time from their consulting partner than would have been needed in 2012. or have a lot more to figure out on their own then they would have back then. This is Now If you're thinking about implementing Salesforce at a small nonprofit today: You have to choose between Nonprofit Success Pack and Nonprofit Cloud. As I've written , NPC isn't appropriate for small nonprofits. But should a small nonprofit choose NPC, I really don't think self-implementing it is viable. The data model is too complicated, the initial setup steps are too numeous and finicky, and the documentation is not complete. Members of the nonprofit Salesforce community are working on this, as is Salesforce itself, one assumes, but I have doubts that it will ever be possible to self-implement NPC. You also, at this very early stage in considering your implementation, will start getting calls from Account Executives, or AEs. ( Spoiler Alert: AEs are Salespeople .) Because of the way sales incentives are structured at Salesforce, you're going to get a lot of pressure to buy things like Unlimited Edition, Experience Cloud, Premier Support, and more. 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. The Salesforce platform and ecosystem has also grown in the last decade. So it's just the case that there are more decisions to be made, more features to consider, and more rabbit holes in the Setup Tree to explore than there were in 2012. I Just Went Through This Hours Though I do a lot more ongoing support and add-on builds, every so often I get to do an implementation from scratch for a new Salesforce org. I just got to the end of one of those projects, in fact. So let me give a transparent view into that recent implementation. (Other than not telling you who the client was, because that feels weird.) To begin with, I estimated the project at around 60 hours . With the benefit of hindsight, that might have been a little low, and I'll probably estimate a little extra padding next time because I strongly prefer to overestimate and come in under. (Then again, these are estimates, so...🤷🏻.) As of the time of this writing, I'm six or seven hours over where I estimated. Plus I want to provide at least a bit of cushion for post-implementation support. As a businessman I have to decide what to do. But bottom line: This implementation went very smoothly, was not very complicated, and was for fundraising only. So sixty hours is just about the bare minimum I can imagine a new implementation requiring. I work quite quickly and have a lot of experience navigating Salesforce's back end. Consider what it would take for an internal employee doing this as a self-implementation and learning Salesforce as they go. Would that take them twice as long? Three times? More? If this is an employee suddenly adding Salesforce to other job responsibilities it might not entail additional line item costs to the organization, but there is definitely a cost for that person to take on the project. Costs Speaking of costs, I do projects like this as a time-and-materials project after giving my best attempt at an estimate. I feel this shares the risk equally between me and the client. Of course, some consultants might do this implementation for a fixed fee. And others might have a lower (or higher) hourly rate. I was charging $176.80/hour for this implementation. (Full Transparency: My rate is $221/hour for Salesforce work. I give nonprofits a 20% discount, hence $176.80. In 2025 my base rate will increase to $230.) So this fairly simple and smooth implementation will be about $11,000. Other Considerations Because I've been doing this for a few years, I have some tools that allowed me to speed things up. Using Copado Essentials makes planning, testing, and executing deployments much faster when I build in sandboxes. (And we always do that , right!?!) Copado ain't free , however. I also have a bunch of metadata saved that used to allow me to customize on top of the NPSP Trial. I couldn't use it the way I did in the past, but that stored metadata gave me a bit of a speed boost in getting the org looking the way I want it. I was able to push that metadata into the client's production org using Salesforce DX. I also built and stored a test and training dataset using Cumulus CI . No Salesforce newbie is going to have access to any of that, even if they have budget to spend. I think it's also fair to point out that I try to put more thought and effort to design and user experience than some other consultants might. So I suppose some time could be saved there. Your Mileage May Vary I'll end where I began: Salesforce is a powerful platform and NPSP is awesome for tons of organizations. But it's just not that easy to implement on-the-cheap anymore. You might be able to do it entirely in-house by a self-taught staff member. A small organization doesn't need a large consultancy. A small organization may not even need a small consultancy or even an independent consultant like me. The Salesforce community is vast and full of smart, talented, experience people, you might be able to get one of them to help you for free. (Though please be careful going this route. I have made far too much of my living cleaning up the mess someone left behind implementing for a nonprofit without understanding the business needs of nonprofits or the architecture of NPSP.) But my experience in the last few years has lead me to believe that someone is going to have to spend at least 60+ hours working directly on a new implementation , from discussions with stakeholders, scoping, and training to architecting and hands-on-keyboard setup and configuration.

It's almost two years now since Salesforce gave us all a gift by allowing five free API-access only integration users (and more cheap) , which contains costs and improves security and audit-ability. But there are plenty of vendors out there that haven't gotten around to updating their packages to explicitly support this. Give Lively , one of my top recommendations to clients, is one of those vendors. But supported or not, you definitely can use free integration users for Give Lively and save some money. You just have to figure it out for yourself. (Or just follow the instructions I'm going to give below.) Meet Give Lively Give Lively is a donation processing platform that's free. (Like a beer, not like a puppy!) That means you can set up your account and start taking donations without any contract cost. Give Lively charges processing fees that vary depending on the transaction type. (Those fees are imposed by the transaction processing networks.) But Give Lively itself is funded by philanthropy and does not charge any fees of its own, nor do they charge for integration to Salesforce. Donors have the opportunity to cover the transaction fees, transparently offered as an option on the Give Lively form. And forms can also ask donors to give an additional gift to Give Lively at the time of donation. As I recall, these are also options you can turn off for your forms. And, perhaps most importantly for you, it's very easy to set up a new Give Lively account and get it connected so that donation data flows to your Salesforce instance. But their documentation indicates that "The Give Lively integration does not currently support the new Salesforce Integration user license type. At this time we recommend utilizing a standard Salesforce user license." Let's Try It Anyway At some point I either hadn't read that, or it wasn't in the documentation yet, or I just decided to ignore it. I think probably I was excited to save a client a paid license and just went about trying it out before Give Lively had even assimilated that Salesforce had released the free users. So I don't think there was documentation saying it couldn't be done, I just had to figure out what to do. There are plenty of examples of apps out there that insist that to work with their tool you need a system administrator profile. Some dip their toe in good security practice and say you don't need a sysadmin profile but that you need permissions to view any object or field and change any setting in the app. While I'll concede this might be required for certain bits of functionality in some apps, it has to be rare. Saying "you need to be a sysadmin" is just being lazy. If you tell people they can only use your app as a sysadmin then you don't have to put as much thought into what missing permissions could get in the way. Give Lively's integration is a good example of this. At its heart, if you think about it, the Give Lively integration just needs to be able to insert an opportunity, contact, and/or campaign. That's eminently possible for non-admin users. ( Please assure me that your fundraising users are not on a sysadmin profile! ) When you log into the back end of Give Lively and work with the Salesforce integration setup, you can see that they've built a tool that will automatically apply permission sets to the sync user. The ability to actually do that requires an admin-type permission. But first of all, that tool is kinda' optional. We could manually grant permission sets. And anyway, you can grant the permissions that tool needs without granting all the other permissions of sysadmin. So at some point Give Lively saying they don't support free integration users is just them being unwilling to work on updating their package. I get it—we're all busy and bandwidth and funds are limited—but if you don't want to change the package, you could still change the documentation. I know there are other integrations out there that require a sysadmin profile because the integration actually checks that the profile of the integration user is System Administrator. (I'm looking side-eye at you, Classy .) That's truly lazy, as I'm sure the user could work with individually granted permissions. But they've hard-coded a profile name and they're not bothering to fix that. I would say that's unconscionable, particularly from a company that is charging a hefty fee to use their platform and an additional fee for the Salesforce integration. (Again, looking hard at you, Classy.) Spoiler Alert: Not Even That Hard So if we ignore Give Lively saying we can't use a free API integration user we just have to figure out the right permissions to grant that user and this is going to work. Fortunately the Give Lively app isn't hard coded to look for a full Salesforce license. (I'm pretty sure you could not have Give Lively log in as a Platform User license because those can't be granted access to Campaigns.) Step 1: Build a Custom Permission Set The Give Lively package installation (which I'm already assuming you've installed) comes with a couple of permission sets for granting users access to the fields from Give Lively. One is called "Give Lively Integration User" and is meant to be granted to an integration user. But since that one is limited to the license type Salesforce (a full license) instead of having nothing in that field, it won't be available to a free API user. So we're going to have to make our own permission set. At the top of Give Lively's documentation  they list the permissions you need to include in this set. Make your new permission set. My name and description are only suggestions: Name : Give Lively Integration Perms Description : Additional permissions required for the GL integration user according to documentation at https://www.givelively.org/resources/salesforce-integration-set-up Allows GL to use a free integration user profile despite what their documentation says. And include the following things within this permission set: Permission Set Overview> Object Settings> Contacts Grant access to any record types used in your org. View All and Modify All Edit access to the field give_lively__User_ID__c Permission Set Overview> Object Settings> Campaigns Grant access to any record types used in your org. View All and Modify All Edit access on all of the fields from the Give Lively package. I count six fields: give_lively__Event_End_Date_Time__c give_lively__Event_Start_Date_Time__c give_lively__Campaign_Id__c give_lively__Campaign_URL__c give_lively__Event_Id__c give_lively__Text_Code__c Permission Set Overview> Object Settings> Opportunities Grant access to any record types used in your org. View All and Modify All Edit access on all of the fields from the Give Lively package. I count 17 fields: give_lively__Anonymous_to_Public__c give_lively__Campaign_Id__c give_lively__Client_Application_Name__c give_lively__Donation_Id__c give_lively__Event_Id__c give_lively__Subscription_Id__c give_lively__Net_Amount__c give_lively__Page_Slug__c give_lively__Page_Type__c give_lively__Page_Url__c give_lively__Payment_Platform_Transaction_Fee__c give_lively__Referrer_Url__c give_lively__Text_Code_Used__c give_lively__Transaction_Fee_Covered_By_Donor__c give_lively__Utm_Source__c give_lively__Widget_Type__c give_lively__Widget_Url__c Permission Set Overview> Object Settings> Accounts View All and Modify All Permission Set Overview>System Permissions View All Data Modify All Data API Enabled Assign Permission Sets Download AppExchange Packages Manage Profiles and Permission Sets Password Never Expires Note: On the objects View All and Modify All may be overkill. And View All Data and Modify All data overall may also be overkill. I have not experimented. But based on Give Lively's instructions, I granted those to see if I could get it to work. (Since they kinda' expect that you'll use a full system administrator, I figured this wasn't much different.) Step 2: Create the User, First as a Full User Next you are going to create a user for your Give Lively to log in as, something like First Name : Give Lively Last Name : Integration Set the email to somewhere you are going to be able to get the password creation message, though possibly not your email directly, it can be a group mailbox. Give the user a full Salesforce license and, for the sake of simplicity right now, a System Administrator profile. [This is not required. You could create this user directly as an API Only if you wanted. I tend to create integrations as user as a full user first. By creating a full user it's nice and easy to ensure that I am able to log in as that user and that it has the permissions I expect. Then I change the user license, profile, and permission sets after I've got it set.] Make sure you set Marketing User = TRUE. Step 3: Set Up the New User Password Get the password creation email and log in as Give Lively Integration. Make sure you know the password. (Consider saving it in a password manager or secure place your colleagues could access it, if needed in the future.) Step 4: Log Out of Salesforce Now make sure that you are fully logged out of Salesforce. If you are still logged in with a cookie, then the next step when you work in the back end of Give Lively may immediately log in as real you, not Give Lively Integration. Step 5: Connect Give Lively To Salesforce Log in to your Give Lively account and get to the place for setting up the integration. [According to this page , " click the 'Get Integrated' button and proceed through prompts."] When you log in, use the Give Lively Integration User —make sure not to log in as Real You! When the login is successful you'll see buttons for applying the Give Lively permission sets to the user. Go ahead and do this. You'll also see a Sync Now button. Might as well test that! In the Advanced Settings tab you can make choices about how you want Give Lively to deal with the data that goes to Salesforce. In particular, this is where you set the record type of opportunities it will create (you don't want it to just use the default record type for the profile it's logged in to—that might not be the right one) and the campaign (if any) that it will put those opportunities on. Step 6: See The Data Flow to Salesforce I now put a real donation into Give Lively to make sure that the data is flowing. If you're still testing Give Lively in your sandbox, they give you a fake credit card number you can use. But when testing the final setup I just make a donation of a few bucks to my client. Then I know it's really working in a real setting. Log back into Salesforce as Real You. Then look for the contact that the donation was made under. You should see the opportunity in their related list. Check that everything looks right. In particular, check that the opportunity was created by the Give Lively Integration user. Depending on your Give Lively settings, it might take a few minutes for the opportunity to sync. You can also speed things up with the Sync Now button in Give Lively. Step 7: Modify the Salesforce User If you've never created an API-only integration user before, you can use my instructions . But assuming you're in a position to set up one of those users, we're going to just modify the user we created in step 2. Edit the user: Switch the User License to Salesforce Integration . When you make this switch you'll get a pop-up warning you that any assigned permission sets or permission set groups will be unassigned. That's OK. We're going to set things back right in a moment. Set the profile to Minimum Access - API Only Integrations . [You could use Salesforce API Only Integrations if it shows up in your org. I don't think there's a functional difference.] Make sure you leave Marketing User checked. Now we've got a user that has access to basically nothing. So we have to assign permissions. Grant this user the Permission Set License Salesforce API Integration . (This is a step you always need to do for an API integration license user, it's not specific to Give Lively.) Now assign permission sets that grant access to the objects and fields the user will need. In this case, what really matters is your permission set Give Lively Integration Perms that was created in Step 1 . But for convenience you can grant the other standard permission sets for users in your org. And for safety's sake, I've been granting Give Lively Additional Permissions that is installed by GiveLively. (Though I found out the hard way that this alone isn't enough for the integration to work, which is why we built our custom one.) Step 8: Test Again in the Back End of Give Lively Now that you've modified the user, I recommend going into the back end of Give Lively and confirming that it still validates. Note that the Apply Permission Sets button will not work for the integration user. This is OK, just ignore the red error. Step 9: Send a Donation Through I don't consider it fully reliable until I've put a real donation through using a real credit card. Within the sync timing, it should show up in Salesforce. Yay! That's All! By following this relatively simple set of instructions you've just integrated Give Lively to Salesforce using a free API Only integration user instead of a full user license. Give yourself a gold star! 🌟 You've just saved your organization $500/year!

I regularly hear people claim that NPSP is "on its way out," or "already dead," or "Salesforce is going to stop supporting it." None of those things are true. Could they become true soon, quickly, or without any notice? Yes, they could. But Salesforce could also decide at any moment to stop developing, kill, or completely change Nonprofit Cloud. Right now I don't think they are going to. But my point is that they could . Salesforce is a giant corporate capitalist enterprise. It fundamentally exists only to make money. If it isn't making money on nonprofits, or through the Industries model, or whatever, it will change what it is doing. And Salesforce is run by people, who can change their mind, or their business vision, or, for that matter, can change jobs. So if the people in leadership were to decide they didn't want to be in the nonprofit market at all, the company could exit it on a dime. If those people decided that the nonprofit price point should double, there is nothing tangible to stop that from happening. (And for the sake of future-proofing this article, I should probably also note that Salesforce could change the names of these and other products at any time.) Where was I...? Oh, right. Don't Listen to the Fear The Nonprofit Success Pack (NPSP) is not going anywhere. It's stable. It works very well for what it does. Thousands of organizations have it installed and use it every single day. Even if Salesforce wanted  to kill it quickly, they could not. There would be a very long tail of organizations still using the product. Besides, Salesforce has repeatedly said that they intend to continue to support NPSP. Sure, we could decide not to believe them. But so far I see no reason to be quite that cynical. Those of you who know me know that I'm plenty cynical. I'm just not that  cynical. I'm sticking, for now, with "Trust, but verify." Support for NPSP will continue, even though further development of it as a product will not. NPSP is Like Cars Let's face it, development of NPSP stopped a long time ago. Long before New Nonprofit Cloud was dreamed up. There haven't been significant new features in the core NPSP offering since Enhanced Recurring Donations, Customizable Rollups, and Engagement Plans and Levels, all of which are more than six years in the past. And some of those were just upgrades to existing functionality in the first place. But just because there hasn't been much development doesn't mean NPSP is somehow outdated. I would argue that development of NPSP slowed and basically stopped because it reached the point that it was meeting the truly common and shared needs of nonprofits. NPSP takes Salesforce, reconfigures the B2B data model to make it work for tracking individual constituents and their households ("B2C," in the lingo), gives us relationship tracking between people, relationships tracking to multiple organizations, and powerful flexible donation rollups. That's basically the common set of CRM needs for nonprofits. Everything else that Salesforce.org used to publish was for a subset of the market—for good reasons! The Program Management Module only works for the program model of certain kinds of organizations. Outbound Funds is great, but only if your organization needs to track...well...outbound funds. Etcetera. And I think this is OK. NPSP reached the point where it was doing what we needed and Salesforce.org realized that when they made new "products" it made sense for them to be optional add-ons, not additional bloat of the core product. Here's my analogy: What's fundamentally changed about cars in more than half a century? Basically they're boxes with four wheels that burn gas to move people around. We invented automatic gearboxes, seatbelts, brigher headlights, cruise control, fancy radar for lane keeping and collision avoidance, and backup cameras. But my great-great-grandparents would have no trouble recognizing today's cars and even taking them out for a spin. Even electric cars are just not that fundamentally different. [I can say this with confidence: I own one. It's great. But when you get down to it, it's just a car.] So I think the future for NPSP looks a lot like the last decade or so: It works great. It's stable. It runs on a state-of-the-art platform that you can customize to the nth degree. There are a zillion organizations (and people) using it. And there is an amazing community of practitioners that work with it and welcome new people to its use, teaching, coaching, and training them. I still think NPSP is the right choice for 95% of nonprofit organizations that are thinking about implementing Salesforce at this moment. And those that are already on NPSP should not be expecting to migrate off any time soon. On a Wild Ride Does any of this mean that the future for NPSP won't be a bit of a ride? No, of course not! Just as two years ago Salesforce pulled the rug out from under all of us by announcing that NPSP would be replaced with NPC, which would be an entirely new system and migration would require a complete org swap, there could be surprises in store for all of us. I'm just trying to remind you that this was always the case. This is where I believe in the power of the Salesforce Community, particularly the Nonprofit Community. We are scrappy, and determined, and smart. If NPSP stops looking viable, then we'll come up with alternatives, whether it's re-creating the core functions through a community-supported free alternative, or building tools, templates, and workbooks for migration. If we come up with some Must Have feature that NPSP lacks and Salesforce is never going to provide, we'll build it and find a way to release it through Open Source Commons, or UnofficialSF, or somewhere else.

With the move to the new Nonprofit Cloud (NPC) Salesforce has made a very intentional decision that they want to divide the market for nonprofits using Salesforce into two distinct segements: large organizations and everyone else. (Side note: when I say "nonprofits," I generally mean "nonprofits and educational institutions." But that's too long to write every time.) Large Organizations For large organizations, NPC and EdCloud might be a good solutions (or might be so someday ). I think I've been clear in my prior blog posts like The Emperor's New Clouds , Extension Objects: There's Nothing to Like , and others, that I don't think the new clouds are All That. But let me assume that Salesforce will manage to fix (or paper over) the problems that I've pointed out. Clearly they're making investments in roadmap for the new clouds. So let me give the benefit of the doubt that eventually the new products will be desirable for organizations planning to adopt Salesforce and that orgs already on Salesforce will eventually see features of the new clouds that are compelling enough for them to want to migrate. (Reminder: If you're currently on Salesforce but want to adopt the new clouds, this is a complete re-implementation .) But barring changes that I can't imagine (and nobody I've talked to can see), the new clouds will still only be appropriate for large nonprofits . When I say "large nonprofits" or "large organizations" I mean universities, national or international nonprofits, foundations, large museums, and the like; organizations that can support a team of multiple Salesforce professionals, including developers, plus probably have cash for a lot of partner/consultant support as well. I really mean large organizations . The data model, back end setup, and feature set of Nonprofit Cloud and Education Cloud are just too complicated for even medium-sized organization to work with. So I say that these clouds might be useful for larger organizations because they can use their greater resources to take advantage of the technology in ways that others can't and to build a lot of customizations, workarounds, tools, training, and documentation that make the extra complexity of the products bearable. And let me be transparent: I don't work with large organizations and I don't have a lot of experience with what kind of setups they have. So I am giving this analysis from an outsider perspective. Given that the large organizations have so many more resources than smaller ones, I think it's probably appropriate (to some extent) that they spend more money and effort on their Salesforce org. They have needs around scale and complexity that would always result in more expensive implementations. Plus, from my perspective, large organizations have (or should have ) the resources and expertise (or can hire/contract it) to caveat emptor. (That means "Buyer beware.") Everyone Else Then there is everyone else that might want to use Salesforce in a nonprofit context. This means small and medium nonprofits. This probably means you , dear reader, or the majority of your clients. I can't say this more strongly: The Nonprofit Success Pack (NPSP) is the right solution for you . (I suppose that comes with a small asterisk. If you're too small, Salesforce itself might not be right yet. Perhaps you should just stay on spreadsheets for a little longer. And there are plenty of organizations that need neither NPSP nor NPC because they should use plain Sales Cloud or Service Cloud or a completely custom other configuration. ) "We're going to become the Red Cross of [insert niche here]!" I know that medium sized nonprofits often think they're going to become large ones someday. Certainly that's the hope of many a founder and CEO/ED of these orgs. It feels like my duty to point out the improbability of this. And anyway, until you are large—really large!—NPC is not a good fit for you. Not today and not, in my estimation, for at least five years (and probably longer). So, yes, plan your system with the future in mind, design for scale, and leave room for growth. But build a system that works for your org as it is today. Don't saddle yourself with overbuilt and extra expensive. If you have a system that doesn't work for your org today you're going to struggle with adoption in the first place. The Nonprofit Success Pack (NPSP) works great. It's easy for users to understand, has many features you and your users will appreciate, and can handle quite a lot of volume. If you really truly do get large someday, such that either you're hitting the limits of what NPSP can handle at very large scale or else just that you have grown to the point that you think you meet the criteria I laid out, above, for using NPC, then and only then would it make sense to go with NPC. Choosing NPC while you are small or medium sized because you hear all the hype from Salesforce about the "innovation" and "exciting roadmap" is not going to serve you well. As I did last week , I'm going to reach for a vehicular analogy: Buying NPC today is like buying a school bus when you have your first child because you're planning to have lots of kids. You'll spend years driving an enormous vehicle that's practically empty. And by the time you've gotten to that giant brood, we'll probably all be wearing personal jetpacks anyway. (One can hope!)

It seems likely that few people reading my blog wouldn't already know about Salesforce URLs, but just in case, let's talk fundamentals today . Whenever you're viewing a page of Salesforce, from the Home page, to a record page, to any part of setup, the URL is a link directly to the thing you're doing. This holds true in all Salesforce environments: production, sandboxes, developer orgs, Trailhead playgrounds, or scratch orgs. URLs are also pretty important in terms of your location in Setup as well. I try not to assume that things are going to work if I work from a Setup URL in Setup because that just feels dicey. But I often will email the link directly to a field definition or an email template. And note that even this official workaround from Salesforce talks about manipulating the URL to go to a place within Setup. Now that you know, you can copy that any URL and email it to someone so they can go straight to the page you were just viewing. (Once they've logged in, of course.) Most of the time I recommend using Chatter as a way to direct someone somewhere within Salesforce. But that isn't always convenient. If you're on a Zoom call, for example, and want everyone to take a look at a dashboard, it's way faster to go there, copy the URL, and put that in the Zoom chat than it would be to @mention each of them from a Chatter post on the dashboard. And when writing documentation, it's really convenient to be able to include links to things like particular list views. The Id's the Thing... The main reason I wanted to mention URLs, though, was to talk about grabbing record Ids. Because if you ever need to get the Id of a particular record, the URL is often your fastest bestest way to do so. There are other options, from a formula field that puts the Id on the page layout, to including it in a report, or a SOQL query or the like. But if we're talking about grabbing the Ids of just a handful of records, it's hard to beat the simplicity of grabbing them from the URL. Load this: https://d4t000000drczua0-dev-ed.lightning.force.com/lightning/r/Contact/0034T0000027laiQAA/view Select: https://d4t000000drczua0-dev-ed.lightning.force.com/lightning/r/Contact/ 0034T0000027laiQAA /view Copy. Reading the Code While we're at it, Salesforce URLs are a bit more complicated than they used to be, but they're not heard to interpret. In some ways, in Lightning Experience this has gotten both clearer and more obscure. But since we basically all use Lightning now, let's start there. Here is a Lightning URL, for example: https:// d4t000000drczua0-dev-ed .lightning.force.com /lightning /r /Account /0014T0000027laiQAA /view [Note: I have added spaces for readability where none would normally exist.] Read in chunks you can actually figure out quite a lot about where you are from this URL. https:// just indicates to your browser that we are viewing a webpage of a secure connection. Then comes the name of the actual org I'm logged into. This is a developer edition org. You probably spend most of your time in an org with a custom MyDomain that's similar to the name of your organization. .lightning.force.com is, of course, the domain for Salesforce itself. /lightning indicates that you're in Lightning Experience. /r I'm not really sure what that's for. [Update: A couple people wrote to me indicating that they belive it's for "record."] /Account indicates—surprise!—that we're viewing an Account record. /0014T0000027laiQAA is the 18 digit unique record Id of the account we're viewing. And /view indicates that we're in View mode, not Edit. Remember how I said this is both clearer and more obscure than in classic. Here's the same record in Classic: https://d4t000000drczua0-dev-ed.my.salesforce.com/0014T0000027lai On the on hand, this is much shorter. At a glance you learn a bit less about where you are. On the other hand, I kinda' miss this Classic format because if I needed to grab the Id it was quicker and easier to do so. It's easier to select the tail end of the URL than the part in the middle, as above, particularly since browsers generally truncate the URL. So you aren't even seeing the record Id until you start working within the address bar. 15 or 18? Did you notice that the Lightning URL shows the 18-digit version of the Id, but Classic URLs show the 15-digit version? The two versions are completely interchangeable as far as Salesforce is concerned. It's just that the 18-digit version is case in sensitive. When using the 15-digit version case matters. So a program that's not case sensitive could consider two records the same that are not. And you know what's not case sensitive? Microsoft Excel. So when working in Excel to do anything with Salesforce data, you're best off using the 18-digit Id. With a record identifier that's 15 characters long it's not very likely that you'd have two that got confused. But it's not impossible either... Working with URLs Interestingly, Salesforce doesn't really care if you keep using the Classic URL format. This is nice because it means you can do less work to go from just having a record Id into getting to the record in question. You can just delete everything after the first slash, paste a record Id after the slash and hit return. Salesforce will load the record, having redirected/translated from your Classic format into the Lightning format. So if you already have https://d4t000000drczua0-dev-ed.lightning.force.com/ And you paste a report's record id (00O4T000001wNWv) on the end, you'll wind up at https://d4t000000drczua0-dev-ed.lightning.force.com/lightning/r/Report/00O4T000001wNWvUAM/view Which, conveniently, is the report itself! I've also found that most of the time you can also just paste a different Id in the middle of that Lightning format and Salesforce will figure it out. This is a "your mileage may vary" situation. But if I'm on an account page: https://d4t000000drczua0-dev-ed.lightning.force.com/lightning/r/Account/0014T0000027laiQAA/view and I just double-click on the Id: https://d4t000000drczua0-dev-ed.lightning.force.com/lightning/r/Account/ 0014T0000027laiQAA /view and paste the Id of a contact —even just a 15 digit version—and don't edit the "/Account/" portion: https://d4t000000drczua0-dev-ed.lightning.force.com/lightning/r/Account/ 0039V00012vl0v /view When I hit Return, Salesforce will happily load the contact page and reconfigure the URL appropriately: https://d4t000000drczua0-dev-ed.lightning.force.com/lightning/r/Contact/0034T0000027laiQAA/view So that's nice.

Did you know that when you're looking at the Id of a record—any record—on the platform, the first three digits tell you what object it's a record of ? For many of you, this is old news. If you've been around the ecosystem for a while, you've probably read about it (like on this blog , or this help article ), or been told about it. But I feel like this bit of Salesforce esoterica doesn't get discussed as often as it should and, therefore, that newbies don't learn about it consistently. This is useful information that every Salesforce admin should know. Last post we looked at how to break down a Salesforce URL. But today we're focusing just on the record Id that's in the URL (or anywhere else you might encounter record Ids, like in a spreadsheet). If I see 0014T000002xyUn, I know that this is an account. How do I know? Because it begins with 001. All account Ids begin with 001. (That tells you something about Salesforce and its history too, right? Accounts are the basis for the data model. All contacts must be related to an account. All opportunities are child to an account...) What we've noticed is that the object is identified with a prefix, known as the Key Prefix , within the record Id. All Accounts begin with 001. Contacts begin with 003. Users begin with 005. Opportunities begin with 006. Leads begin with 00Q. (Fun to speculate: I assume the Q is from "qualification.") Reports begin with 00O (that's zero zero letter O). If you want the truly complete list, let me direct you to Daniel Ballinger's list on Fish of Prey . Isn't it interesting that Account is 001 and user doesn't come along until 005? I assume that means that Parker built out the data model before bringing in the concept of logged in users interacting with the data. And what happened to 004...? Your custom objects get assigned a key prefix as well. They usually start with a lowercase a. (Maybe they always start with a lowercase a?) [Updated with a side note: Phil W pointed out to me that Id prefixes for custom objects can vary from org to org because of what might already have been in use before. If you install managed packages in a different order in two orgs, the custom objects for those packages could vary. This would apply even to the objects of NPSP, since it's theoretically possible that your org had some custom object using one of the prefixes before NPSP was installed in your instance. So don't make assumptions and don't hard code. ] Flows on Tasks Have you ever wanted to kick off automation, for example, "when someone creates a task related to an opportunity (via the Related To field)"? I get that kind of request all the time because someone wants to do something automatically if anyone has put a note on a grant, or a note on a partnership discussion. But while this seems simple at first glance, you quickly realize this isn't going to work because that Related To field (known by its API name, WhatId) can look up to just about any standard or custom object, it's not just a lookup to opportunity. But if you know about key prefixes, you can make a task that checks the first three digits of the value in WhatId to figure out if it's on an opportunity. Easy peasy! Decoding Errors The other place I find key prefixes useful is when trying to interpret an error, either in the UI or a flow error email. If the error message isn't very helpful—And, let's face it, that's more often than not!—it becomes a treasure hunt to figure it out. You have to understand the full context, such as what user was unable to do what thing, when/how they were doing it, etc. But often the error isn't directly related to what the user was doing, and instead has to do with other records that are updated because of what that user was doing, and the user doesn't have sufficient permissions to create/update/delete that other record. The Id in the error message might let you know what didn't seem obvious. For example, I see that I ages ago I had a question in my email about this: ERROR: INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: insufficient access rights on cross-reference id: 0014S000003rlts Immediately upon looking at it, I know that this has something to do with permissions regarding Account. Maybe the integration, in this case, was trying to update a contact or an opportunity, but it's account permissions that got in the way. Now I know where to start. Or this one: npsp.TDTM_Opportunity: execution of AfterInsert\n\ncaused by: System.DmlException: Insert failed. First exception on row 0; first error: INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY, insufficient access rights on cross-reference id: a2A000005Lthc A little sleuthing and I was able to figure out that a2A is the NPSP Data Import Batch object (npsp__DataImportBatch__c). Combined with knowledge that this error came from GiveLively (a donation platform), that might still leave a lot of troubleshooting to work on, but I already know a lot more than the original message conveyed! One Last Trick You can use the three digit prefix to go to the tab for the object it indicates. This won't work in all cases, since some objects, standard or custom, don't have a tab. But if you know the prefix for an object, or are looking for the object based on an error message, you can make a quick link to the tab with the prefix. For example https://yourdomain.lightning.force.com/006 will take you right to the Opportunities tab. Swap the 6 for a 3 and you can jump to the Contacts tab. Etc...

If you've tried it at all, you've probably noticed that the Salesforce mobile app acts significantly differently than interacting with the platform through a browser. I have to admit that I've only used the mobile app infrequently and, as far as I can tell, few of my clients have used it at all. So I don't pay it much attention. There are some Salesforce admins out there, like Terry Cole , that have put a lot more thought into the mobile app and a lot more encouragement for their users to adopt it than I have. But recently I had a client, Carol, that adopted the mobile app for herself. The main thing she wanted to do was upload a photo someone had texted to her to that person's Salesforce record. Seems like it should be [relatively] easy, right? So Many Actions Have you ever been working in the page layout editor and wondered about all the actions that show up in the "Salesforce Mobile and Lightning Experience Actions" section? Half of those, I'm not even sure what they really do, or if they work. And others are irrelevant clutter in this context, such as Submit for Approval , when there is no approval process for the object I'm working on. Plus there are the redundant ones, like New Payment , that replicate the function you could just get using the New button on the Payments related list. You may have tested this and noticed that lots of these don't actually show up for users (or you) because they relate to features that aren't enabled, or the like. Well I don't know about you, but that kind of clutter drives me crazy. It becomes hard to ensure that I've ordered the buttons in a useful way, not to mention that I haven't left on one or more that will confuse people So the first thing I do when I'm editing a page layout is to remove everything but the handful I actually want to display to users. So here's the button setup for a custom object called Onboarding: I removed a whole bunch that never get used and I've ordered the remainder in a way that generally makes sense for users: Cancellation Checklist (This is a regularly used custom quick action that had been built before I worked with them.) Change Owner (Onboarding owners are the people in charge of the record.) Then we have three buttons that actually show together in the Activity feed, not the button bar: Email , New Task , and Log a Call Printable View is rarely used, so I put it toward the end of the list. Change Record Type probably shouldn't even be here, as this object has no record types. (Since it doesn't display, I've never noticed that I ought to remove it.) Clone might sometimes be useful. Edit is often needed and I usually put it first of second. (I'm just noticing that it's in the wrong place now! But I think users in this org tend to click on the pencil icons instead of the Edit button anyway.) Post doesn't show up with the other actions, it displays in the Chatter publisher. And finally we put Delete last on the list because it should be the least frequently used. (Often it will end up under a carat if there are a lot of buttons on the page.) Here's what those result in when you're actually on a page: Better for Users than Admins Quick side note here: The final button order looks pretty good for users . (Though, as noted, I think Edit should be third and I'll probably make that change when I finish writing this post.) But the order in the page layout editor as an admin is confusing, particularly due to those actions that don't display in the button bar (like Post) or, like Change Record Type, don't display at all because there are no record types. On my best days, I'll reorder everything so that those ones are grouped at the beginning or end, or take them out of the layout entirely to reduce clutter. But other times (like, apparently, in this case...), since I know which ones display in their own places, I just leave them where they fall. What can I say? Sometimes I'm lazy. 🤷🏻 No New Button on the Files Related List in Mobile What my user, Carol, found was that even though she has no trouble uploading files to Onboardings in a browser using the Add File button in the related list, she wasn't able to figure out how to do it on mobile. The related list looked like this: Notice that there's no New or Upload button. When she asked me about it, I was confused too. How I Solved It It turns out that this is one of those situations that cleaning up the clutter created its own problem! The Files button that you probably see all the time in the page layout editor but doesn't show up when you view the page is actually what enables mobile uploads! So I had to edit the onboarding page layout to have these options in the Salesforce Mobile and Lightning Experience Actions section: See how I've added File second in the list? Here's an Onboarding record in a browser now: File does not appear there. But if you pull up that same onboarding on your phone: File is right there after Cancellation Checklist. So now it's possible to attach a photo from your phone to an Onboarding record. What seems like "clutter" can sometimes serve a purpose.

If you're like me, you're probably drowning in all the announcements from Dreamforce 2024 about generative AI (genAI) features under the Einstein and Agentforce branding. And you're probably asking yourself, as I am: "How much is this stuff going to cost?" These genAI features are going to be far from free. You're going to need the right kind of licensing and you're going to consume credits. Licensing The picture on licensing cost is starting to come into focus. Any user that is going to actually use genAI will need to have a proper license. Using genAI means sending a prompt to a generative pretrained transformer (GPT) and getting back results in the form of text, created or rewritten. Users that aren't the requester or the direct recipient of the AI answer should not need an AI license. Licensing your users starts with two options: Einstein 1 Edition This is a rebranding of Unlimited Edition, with Einstein for Sales/Service bundled (see below), Data Cloud (presumably with more credits than the free allocation), and some other things. ( You might recall how I feel about UE. ) With nonprofit discount these licenses are $3,600/user/year (down from list price of $6,000). So to summarize, my understanding is that if you're on Einstein 1 Edition then you pay for genAI features for all users, whether they send prompts to EinsteinGPT or not. Einstein for Sales (or Einstein for Service) This is an add-on license (probably a Feature License) that can be assigned to a user to enable genAI tools. It's my understanding that you can buy these add-ons only for the users that need them , which will save a lot of money. You're not going to need GPT for every person in your org, since some people will not send prompts. Your AE will probably imply that you should get one for everyone, but you should not . ( Spoiler Alert: AEs are Salespeople. ) The Einstein for Sales/Service add-on is $900/user/year at list price. As of this writing, I have not yet seen a nonprofit discount price. Since Einstein 1 Edition for nonprofits, above, comes to 40% off list price, I expect the nonprofit discount for Einstein for Sales/Service will probably be similar (so perhaps $540/year). [PS - I don't think there's really a huge distinction between the Sales or Service versions, they're naming that's meant to parallel the licensing naming. ( Don't buy both  Sales and Service if you're a nonprofit!) ] Even if you economize as much as possible, it's looking like a minimum of more than $500/year to get AI features, for just a single user. Valid testing, let alone usage, is going to require at least the admin and one business user. That could become a significant additional annual cost to your "free" nonprofit software. By the way, with all the announcements leading up to and during Dreamforce, I'm writing this without a clear understanding of whether "Agentforce" replaces the "Einstein for" branding or if Agentforce represents something entirely new. GenAI Credits Once you've got the licensing in place, you're going to consume "credits." This is where I really can't help much with specifics. I'm not sure anyone can yet. First of all, I've asked around and have yet to understand which actions will actually consume a credit, or whether certain actions consume multiple credits at a time. If you read carefully in the nonprofit pricing guide PDF , you might have noticed that Nonprofit Cloud Einstein 1 Sales entitles you to "All features in Unlimited Edition plus Einstein for Sales (25K AI requests per user per month)..." I think that implies that 25K requests per month is also the allocation you'd get if you bought Einstein for Sales on its own. (But don't quote me on this.) Twenty five thousand AI requests per person per month sounds like it could be quite a lot. But is it? If the idea is to individually personalize fundraising emails to your entire list, that could soak them up pretty quickly if your list is large. It seems like it should cost a minimum of one credit per person on the list, since you would be asking EinsteinGPT to personalize to that potential donor. But at least you know exactly how many people are on your email list and how many email appeals you want to send. The other commonly-discussed use for GPT is for something like a customer service chatbot. A university might want to have a registrar's chatbot that can answer students' questions about course add/drop, or a comptroller's chatbot to help them make sure their student account is paid. Estimating credits for those use cases seems a lot less straightforward to me. I would assume a credit is consumed with each response in the chat. (Surely it's not just one credit per conversation.) Deploy that chatbot where a lot of people might use it (kinda' the point!) and you could start soaking up credits fast . We got at least one pricing clue in a September 12 press release from Salesforce. It's a rather long read for a press release, but at the very bottom you find, "Agentforce pricing starts at $2 per conversation; standard volume discounts apply." In some ways that generates more questions than it answers. Are "conversations" the same as the "requests" I was quoting numbers for above? Do you have to buy some bundle of conversations up front, or is it entirely based on usage? Does building and testing in a sandbox come free or still cost per conversations? What, if any, licensing is required to access Agentforce for Sales and Service? How will you know if you're going to get a huge bill? Plus doing a lot of this this might also require that you consume some (or many) Data Cloud credits at the same time...? Data Cloud Which reminds me: I've heard several references to possibly "requiring" Data Cloud in order to use Einstein genAI features. I have little to no understanding of what that actually means or whether you would need to have something beyond the free Data Cloud that every org is entitled to. I can see why this would be required if you wanted to combine your Salesforce data with data in other systems (email marketing, web click tracking) before you send it to EinsteinGPT. But I don't know if Data Cloud would somehow be required if you only want to use Salesforce data. If you have to purchase Data Cloud beyond the free allocation, my understanding is that it starts at $100,000/year! (Plus the cost of implementing, of course, which you're surely going to need a large consultancy for.) Nobody Knows 🤷🏻 Let me be fair to Salesforce here, though: I don't think they know how consumption-based pricing is going to work either. Their costs to provide these services to customers are consumption-based, because that's how cloud computing services are priced, whether genAI or elastic web storage. So they have to balance a massive uncertainty in how much their costs could balloon if people adopt these features. They're trying to offer the fancy new features that they think people want while figuring out the cost, pricing, and revenue models all at the same time. It certainly seems like the wave of the future for Salesforce costs will be more consumption-based and less fixed-price license based. But the actual outlines of that pricing are still pretty hazy.

I'll be presenting at Dreamforce in a couple of weeks, which I'm very excited about. [I hope I'll get to meet you there! If you're a reader, please say Hi. I'll even give you some stickers!] If you have never been to Dreamforce, it's quite...something. Over forty thousand of your closest friends, in packs of Trailblazer hoodies , taking over the streets of San Francisco . I should say it's probably not worth the cost for most people compared to going to Dreamin' events . (In fact, I should probably write a whole post about that!) But Dreamforce is something to see. I think everyone in the Salesforce ecosystem should experience the Mother of All Salesforce Events at least once. I mean, I got to see U2 at my first Dreamforce. It's not all conference rooms and PowerPoint. So if you're going to Dreamforce this year, or thinking about it for the future, here are my top tips for surviving and thriving. Comfortable Shoes 👟 I'm kidding here. Yes, you should wear comfortable shoes. You're going to spend all day on your feet. But this piece of advice has been given in a million blog posts, podcasts, and Trailblazer Community posts already. It was just a joke for me to throw it in. This post is not meant to be a rehash of what's been written before. Shorten Your Lanyard 🏷️ I've been on the record many times as a fan of name tags. And your Dreamforce badge is truly required to get into any space of the conference, so you're going to be wearing it all the time. Make your name visible by shortening the lanyard. I usually tie a small knot in the lanyard, which raises the badge closer to my chest than my stomach. If you're wearing a hoodie, you can put the lanyard around the hood, instead of just on your neck. If you have a collar, put it outside that. But I still think tying a knot is the best way to go. The benefit here is that even when you're sitting down, other people can see your name easily . Trust me—you'll appreciate it when you can remind yourself of the name you didn't quite catch over the noise. Skip the Marketing Sessions - And Too Many Are Marketing Sessions There's just no way around it, if a Salesforce employee is delivering the session, it's almost certainly going to be marketing. Lots of blah blah blah about the hot new thing and how it will change everything. (Last year and this year: Generative AI.) In my opinion, these are total wastes of time. This applies—perhaps especially applies —to the keynotes. (Yes, all the keynotes. Marc Benioff puts on a good show, but the main keynote is nothing more than an advertisement for new "features" that you probably won't ever use.) And anyway, you're going to hear about the main marketing push ad nauseum in a million other places. The main keynote doesn't have any other sessions happening at the same time, but there are plenty of other things to do with your time. As for the rest of the keynotes, I say look for sessions where you can learn real skills or meet real people instead. The other kinds of sessions I find tiresome are those where a partner presents with their customer about a big implementation. You can usually spot these with titles like "How the Food Relief Society Served Ten Million Meals" or "Quilts for Cats's Digital Transformation." The partner is there to market their company, sharing the stage with a customer that just spent tens or hundreds of thousands of dollars on a project. Salesforce gave the session a stage based on a recommendation by the sales team, with a marketing goal, not an educational one. With an implementation that big, the partner could never present all the nuances. The resulting presentation is too-simplistic and lacking in detail, leaving admins with little they can take back and use for themselves. But that isn't the goal of the session. The partner (and Salesforce) want executives at potential customers to be wowed so they'll do their own big implementation. As a hands-on-keyboard practitioner, I find these about as useful as the demos in the main keynote. Those demos are cool, but all I can think as I watch them is, "How many millions did this take to implement? And how much would it cost in annual licensing to support that org in real life?" Find the Right Sessions 🔍 So what sessions are worth adding to your agenda? Look for three categories: Anything presented by members of the community. These are going to be practical How To kinds of sessions, with real demos. (I'm biased, of course, since this covers my own session.) Community Cove events. These are also usually created/hosted by community members, though sometimes organized by Salesforce itself (members of the Trailblazer Community team). They're more informal, less "session" and more networking and discussion. Sessions run by Product Managers. This is the major exception to my rule, above, about sessions run by Salesforce employees. The product managers are actually building features, so these are chances to learn from the maker, see the roadmap for feature upgrades, and ask questions. Dreamforce has relatively few of these sessions, as they're more a focus at TDX. But read the Agenda Builder carefully and you'll find some. A special session worth mentioning here is True to the Core , which also features product managers, through it's actually facilitated/moderated by Parker Harris and senior technical leadership. This is the biggest, most public, place for admins to ask technical questions and advocate for feature improvements and interface upgrades. Network Network Network 🛜 The real reason to attend Dreamforce is to meet and hang out with people from the community. Sessions are interesting, of course, but the real value is in the people. When you're stuck on how to build something later these are the people you'll be able to ask. So introduce yourself to people in lines, sitting next to you in breakout rooms, and at meals. You never know when you'll run into someone you recognize from Ohana Slack or threads on the Trailblazer Community. Now you can pal around for a bit and turn a virtual contact into a real life friend. Pro tip for particularly for introverts: Find yourself a "Conference Buddy." The crowds are going to be overwhelming. But if you can find one person and connect with them for a bit, you'll be reenergized. Watch the online communities for events for newbies, including the Bacon Breakfast , the annual walk across the Golden Gate Bridge, and others. Definitely go to the First Timers meetup . These are great places to meet people who are also looking for a friend. Do the Quest—it’s fun! 🏅 Salesforce has significantly cut back on the massive swag load of previous years. But they still build in some kind of "quest" with good prizes like shirts, hoodies, and plushies. You usually have to attend a session or two of particular kinds, do a Trailhead module, and meet with some of the sponsors. It's not that hard. Check the Events app for the requirements and what the prizes are. There's usually also a paper handbook available at the information booths. Even if you have no interest in the prizes themselves, the quest can be fun. Plus it's something to do with people as you get to know each other. I have great memories from speed-running the TDX quest in 2023 with the Four M's (me, Monica, Misty, and Melissa). Besides the silliness of getting the prizes as quickly as possible, we had fun at the "escape room" and some of the other goofy games. Plus sometimes you might actually learn something, discover new products, features, or apps that you didn't know about, or even meet a product manager or find an exhibit booth you woud never have come across. Feed the Circular Economy ♺ Even if you don't care about the quest prizes and swag from exhibitors, you probably have someone in your life you can bring things back for. So take the good swag. Maybe you don't need yet another re-usable bag, or phone battery, or even hoodie. But your coworkers might appreciate them. (Or your family.) If you aren't into "stuff," that's fine. But you can be judicious. Only take the good stuff. Socks don't take up a lot of space. Plushies are bulky, but you'd be surprised how much people love them—even people that don't know the Salesforce characters. Stickers take no space at all. And yes, I'm aware of the environmental consequences and the waste swag can represent. But a few fewer stickers or pens taken from Dreamforce are not going to save the world. And if they'll bring joy to someone, that's got value. Your company sent you all the way to Dreamforce, you can share swag with coworkers as a sign of your appreciation. Or save the haul to bring with you to a user group or Dreamin' event. There are plenty of people that are involved in the ecosystem that don't make it to the big events or don't get their hands on a piece of swag they were hoping for. The more you give away, the more you build friendships in the ecosystem and spread the fun. Eat 🍴 For my last piece of advice, I'm turning to the practical: Don't forget to eat. Your Dreamforce registration comes with lunches. You need fuel to keep going. So make the time to eat. Bonus points if you manage to eat with one of your new friends. But even if you just need some time to sit quietly by yourself, get those healthy calories in when you can. And this applies doubly to dinners, in my experience. Lunch is at least served for everyone on the Dreamforce campus. (It might not be the perfect food you wanted, or the options might run out, but it's pretty good, relatively healthy, and will keep you going.) But dinner is on your own. You might manage to get food at one or another party, if you attend them. But I've learned not to count on that. Sometimes the food is insufficient. Or it's all gone by the time you arrive. Don't compound the exhaustion and the jet lag by also not having dinner. Grab a few people and head to a restaurant when the long day of sessions ends. Don't be shy: You can be certain that any group you announce a dinner plan to will have at least two or three people that want to eat with you! I also like to swing by Trader Joe's and grab some supplies to keep in my hotel room, both for breakfast and to keep some snacks with me during the day.

I've been working on an approval process for a client lately. I bet that's for a sentence you don't hear too often. But despite not having gotten updates in ages, they're a pretty cool feature. However, this post isn't actually going to be about approval processes. It's just that our story starts there. You see, I had a pretty simple requirement: Each step in the approval would move a record to the next stage. But we wanted to require certain fields be filled out at certain stages, as the record advances through the approvals. Page layout tricks wouldn't be the answer, since some approvers would only be approving, not editing the record. Time to write a validation rule . Only when I started testing, I found that records kept changing status and ignoring the validation. Thing I Learned: The workflow field updates that happen within an approval process do not fire validation rules. Fortunately, a few minutes' searching found me at this blog post , by Yumi Ibrahimzade, with a workaround. Build a before save Flow that checks if the record has certain conditions and then use a custom error component to show an error, similar to a validation rule. Problem solved! So interesting! I had never used the custom error component before. Idea! 💡 That got me thinking. This custom error on a before save Flow is pretty neat! Cooler than validation rules 😎 on a lot of levels. With branching logic and all the other powers of Flow, you could get super custom with what kind of validations you want. For example, you can make cross-object validations, that check the status of related records, not just fields on the record itself. Or you could validate based on non-record statuses, like day of the week, or user attributes, or even custom metadata records. Here's Yumi combining custom errors with Flow fault paths, so fault paths don't cause a Flow to fail silently for the user. I want to use these before save validation flows everywhere! Reality 🥱 But in truth, I'm sticking with validation rules. Sorry to be the splash of cold water. Validation rules have two major advantages: Transparency As much as the backwards formula logic of validation rules constantly trips me up (and it does!), they live right within the object manager. You can see all the validations for a particular object in one place. And you can also see what validation rules relate to a particular field right within that field's edit page. Ease of Maintenance I absolutely love Flow. But it takes more than a handful of clicks to make a new one. Or to open an existing one. Or even to activate and deactivate flows that are already built. And don't even get me started on the pile of Flow versions. So if you need a validation rule that can be built with a rule, it's going to be far faster to create a validation rule. Fewer clicks = happier admins. Let the Gears Turn ⚙️ But now that we both know about this, let it rattle around in your subconscious. Can you think of validations that would help keep your data clean that weren't suitable for validation rules?

You know what's also part of the design of your Salesforce pages? A whole lot of text. So far I've talked about color, eye movement, where you put fields, and more. But there is text around all those things, from field names/labels to the content of the fields themselves. Those are all part of the design! Field Labels When you create a new field, how much time do you really spend thinking about the label? If you're like me, it probably depends a lot on the context. Organizing a spreadsheet listing all the fields that will go into a new object I'm scoping out? I probably take some time to consider the labels in conjunction with each other. (And my stakeholders might have opinions as well.) But throwing together one or two fields as I'm making an automation or responding to a user request? Those field names happen more organically. Those two situations can result in very different sets of field names. This is my reminder to spare a thought for how field labels are going to interact with page design and other uses (like on a report). You get forty (40) characters in a field label. That's it—there are no workarounds. Keep this in mind, particularly when you're about to create a whole series of fields that you want to go together. If you have one that's going to be longer than the rest, best to abbreviate them all from the start than to realize the problem late in the game. If the labels in a section don't look like they go together that's going to be noticed at least subconsciously by your users and give just a little hitch of distaste. Nobody want's that! Balance Consider the screenshot below. It's not perfect—none of my designs are. But it works well enough. You've probably seen a phone/email section that looks a lot like this before. I'm quite happy with that section.. The phone fields on the left are grouped logically together. The email fields on the right parallel them. In the case of this org there is one more email field than phone field, so the right column is a little taller. But that imbalance makes immediate sense so I don't think it is a problem. Then the Career Fields of Interest section is balanced with just one field in each column. (Note that it somewhat violates a suggestion I make below. But I'm not perfectly consistent.) Then the Communication Preferences section has four checkboxes. They're all in a single column because even though it makes the overall page taller (more scrolling = bad), dividing them into two columns would make the logical grouping hard to figure out. And I expect people will collapse this section most of the time, so the height matters less. Help Text First of all, consider this my plea for including help text as frequently as possible as long as it's useful. Users really do appreciate it when it's there! This can take a moment extra each time you make a field—and particularly when you're making a bunch of fields at once—but it's worth your up-front seconds to save users a minute or more of confusion later. Let me also note the aesthetics here: If some fields have help bubbles and others don't it can make your page layout look uneven or unbalanced. We wouldn't want that! No, seriously. We don't want that. Notice the screenshot above, where two fields in Communication Preferences have help bubbles and two don't. That bothers me. I might need to to fix it right now. In a perfect world I would say that all fields in a section should either have help text or none should. But the world isn't perfect, so you'll have to weigh the small clutter or unbalance with the useability tradeoff of the guidance. Guidance Speaking of guidance, here's one of my favorite tricks: See how there are fields in this Phone Interview section that start with a 🗣️ emoji and then actually have the what the user should convey to the stakeholder? Without having to use a screen flow we've converted part of a record page into a script for a phone interview itself. How did we get these guidance sections onto the page? Simple! They're text formula fields. Not complicated formulas, either: This trick allows you to place text within the detail page layout instead of having to put it in a rich text component above or off to the side! 1 or 2 Column Sections Probably one of the things that drives me most nuts is when I see someone's page layout that has a long text field in a single column. It's just...wrong. It's one of the first things I clean up when I work with a new client. (If I can get agreement to change page layouts.) If you're going to make space for your users to fill in a longer narrative it should not be squished into a single column. It will be hard to read, wrap funny, and force users to scroll further to see things below that field. Put those fields into a one-column section—on their own if need be! If you create a one-column section and turn off display of that section's header it will act as though it's part of the section above it (even collapsing along with the collapse of that section). Look no further than the standard Description field on Account. Salesforce puts it into a two column section by default for a reason. And when you create a new long text field and have Salesforce auto-add it to a page layout, it goes into the bottom of the first one-column section, while most other fields go to the bottom left column of the topmost section. This different behavior exists for a reason! By the way, multi select picklists should get similar treatment. When there are multiple items selected, MSPs look like long text (separated by semi-colons). And in edit mode you're going to need room for both the choices and the selected choices. Look how squished an MSP looks when it's in a single column in edit mode: Isn't this better? Related List Details Here's another trick I like to use. It can be hard to glance at a related list and get all the information you might want about records there. So create a formula field on the child object that pulls together a few fields' worth of information and display that field as the prominent column in your related list. Now you probably don't even have to open the child records. Here are individual grades on a student's report card: The Detail column tells me what I need to know without having to add three columuns to the layout. Or you can put details into the name of a record using a before save flow every time the record is edited. These college applications' names tell most of the story. Design Is Not Just About Imagery and Color When you're adding text to your Salesforce pages, that's part of the design of the system, whether that text is a field label, the contents of a field, or the text within a help bubble.