Search Results

Recently I've been presenting at user groups and conferences on the theme of page design. How can you design your Salesforce to make your colleagues more efficient, accurate, and happy in their work? Too often we, as admins, don't take time to think about design and the user experience. These aren't new ideas. It's a while already since I wrote about the 50/50 split. (If you don't remember that post, I'll forgive you. I can sum it up: Don't use Salesforce's default Lightning Record Page template! Changing your template to give two equal columns lets your users take in more information more quickly when they look at records.) I'm going to assume that you're already working with a page template that can show your users the information they need. But let's go a step further than just the overall page frame. Let's ask, "Where am I putting fields?" Page Layout Editors Things don't get much more fundamental in Salesforce than page layouts! You've got two fundamental editors for your page layouts: The "enhanced" [before I even got into the ecosystem] page layout editor. Basic and functional. New-and-shiny Dynamic Forms right in the Lightning App Builder. Let's start by thinking about where you put fields, not how you get them there. Go ahead and use whichever tool you prefer. Both have their pros and cons. The considerations for placement don't change. If There's a Need, It Leads Most of your required fields should be toward the top of the page layout. You probably already knew this, but it's worth specifying. And I bet now that you're thinking about it you can come up with some places where you could do better. Ever have that problem where you're trying to throw together a quick test record and you can't do it without scrolling all over the page to fill in a bunch of required fields that aren't grouped? So frustrating, right? Perhaps that means the page layout needs some love. If there are fields without which a record would be entirely meaningless—or even impossible (such as those required at the database level)—then your users are probably planning to fill them from the moment they click New. Help them with this. Put required fields right at the top of the page, in the first section a user encounters. Even if a field isn't actually required on the page layout, the sooner a user comes to it on the New Record screen, the more likely they are to fill it out. Make that first section count! Of course the most obvious example here are Name fields. Just as the First Name and Last name fields are the first and second fields you expect to enter when creating a new contact or lead, every other Salesforce record has a name field of some kind. If it's one your users will fill, put it in the top left spot—the first field they encounter. Auto-numbered records don't accept user input for the name, so they aren't a factor for data entry. But I still prefer to put an auto-numbered Name field pretty close to the top. That way when we need to refer to it we know where to look: in the same place we would look for any other record. If we're talking about a record that has a Stage (or Status), such as Lead, Case, Opportunity, or so many custom objects we've all built, I'm going to argue these probably go pretty near the top as well. And that brings me to the next principle. Like Things In Like Places Those Stages (or Statuses) are important, so they're going near the top of the page. And generally I want to put them in a similar location for all objects. That way, even without thinking about it, on any record my users know where to glance to find the current stage. On my pages these fields are usually at the top right of the first section on the page. My users get subconsciously trained that whenever there is a Stage, it's a picklist they adjust at the top right, probably next to Name. Actually, I think I got trained by Salesforce. The default location for Stage on an Opportunity page (in Classic) is toward the top right. That's probably how I got into the right-column habit in the first place. Of course, there are all sorts of other ways users are going to interact with Stage, such as with a Path component, through Lightning Messaging Utility banners, through a Quick Action, or perhaps the stage changes through automation. But whatever underlying field is represented by a Path or banner I also put directly on my page layout. That ensures ease of editing in the full Edit modal, makes it available to adaptive tools like screen readers, shows it in obscure places like the printable view, and even makes it available for editing in list views. Got an object with a Start Date and End Date (like Campaigns)? Make sure you keep them together! There's nothing more frustrating than entering the start date and tabbing into the next field only to find that it's not the end date. I tend to put record Owner on the right and toward the top for any objects where it's actually used. There are other reasonable placements, for sure. Just be consistent. [If Owner isn't important for your organization there a few objects you won't be able to remove it from. In that case, bury the field somewhere it won't be obvious, probably down with the rest of the system fields, so you at least reduce the visual clutter.] Speaking of which, you have to decide how you feel about the system fields. There's a valid argument for taking Created By, Created Date, and Last Modified Date off the page to just reduce overall clutter. On the other hand, particularly for sysadmins, these can be very helpful fields. I leave these on all page layouts, even for simple objects with just a handful of other fields. I also keep the default System Information section, I turn on the header display at all times, and I leave the section at the bottom. I usually even add one more blank space between the last substantive field and the header of this section. For those users that know, they can collapse the section and it will stay that way for them in the future. And even those that don't collapse it have that extra space to clue them in that they can stop reading before that last section. Consider Removing Fields I mean it. There are fields you don't actually need to be on your main page layout. "Main layout" meaning the "Details" component of most Lightning Record Pages. There are all kinds of fields you can move off the details section and put behind a tab or somewhere else on the layout. NPSP has dozens of donor rollup fields, for example. Most users aren't looking these when they go to a contact page. And if they are looking for the rollups, it's easier to find them with one click behind a tab than to scroll down looking for the right section. Fields that users don't edit, like rollups, are great candidates for putting behind a tab. You never need them to show up when the user clicks Edit and gets the fullscreen editing modal. With Lightning there are all kinds of other field moving possibilities. If you have a handful of fields that are only edited occasionally, and only together, not in the context of other record updates, you can put those fields together behind a tab. Teach your users that's where the fields are and that they can edit them using the pencil icon. Bam! Now you've made users more efficient (fewer fields to wade through when editing) and happier (able to see just the fields they want when they want them). You're a hero, just by taking some fields off the page layout and putting them somewhere else. The How of Moving Fields Around Now that you're thinking about why, when, and where to move fields, let's take a moment for the How. There are two ways you can do this: The Related Record Hack My preferred field moving method is known as The Related Record Hack. Despite what I call it, this is a Salesforce-built and -approved feature. As described in this post I wrote on that other blog several years ago, you create a Quick Action and place it on the page using the Related Record component. "Hack" in the nickname refers to the fact that you accomplish it using a Quick Action and a Related Record component, though it's neither to take any action nor to display a related record (just the record itself). Dynamic Forms Clearly Salesforce is moving in the direction of Dynamic Forms. Using Dynamic Forms you can place single fields, build field sections, and conditionally hide or display as you desire. Full disclosure: I'm not using Dynamic Forms yet. There are a handful of limitations and frustrations about the feature that have kept me away. Each release is making this feature better, for sure. In truth, the main thing holding me back is that I switch between orgs so often. It would be a pain having to constantly juggle between the two methods. That was Just Step One Who knew I would have so much to say just on the topic of moving fields around on your page? But this is just the beginning! There are all sorts of things you can do to make your Lightning Record Pages more fun and interesting, including adding color, directing your viewers as they scan your page, and more. Watch this space.

Previously, I explained how hard it is to do some simple kinds of reporting in the new Nonprofit Cloud and Education Cloud. In particular, I was looking at the impossibility of making a report that would show people (Person Accounts) and their donations (Gift Transactions) while also being able to show or filter based on donation rollups, like Total Giving (over their lifetime), Gifts This Year, etc. The problem stems from the fact that giving rollups, in the new clouds, do not reside on the account record, nor even on the contact record. They're on an extension object called Donor Gift Summary. I wasn't going to leave my client without the reports she requested, particularly since I think her requests are entirely reasonable. So I found a workaround. But I don't love it. I’m a little afraid it could introduce problems in large data volume environments. Still, it works and I'm proud of having thought of it. So I'm sharing it with you. But caveat emptor and YMMV (your mileage may vary). A Lookdown Relationship Step 1 is to create yourself a new custom field on account. I called mine DonorGiftSummary. This is a lookup field, to…wait for it…Donor Gift Summary. This is a lookup field. But it’s really a "lookdown" because Donor Gift Summary is already a child object to Account. (It has a lookup field of its own, called DonorId, that looks up to Account.) Yes, I'm intentionally creating a redundant field here. Dolores Does the Work Next I built a DLRS rollup to fill the DonorGiftSummary field. Parent: Account Child: DonorGiftSummary Field to Aggregate: Id Aggregate Operation: First (or last, since there is only ever one DGS) Mode: Process Builder In plain English, what that rollup does is take the Id of the Donor Gift Summary that goes with each account and put it into the DonorGiftSummary field. Because it's set to the mode "Process Builder," this rollup will only fire when called by other automation. I then used DLRS's Schedule Full Calculate button to set this rollup to run once per night around 4am. (If you want to hate on DLRS, you’re welcome to fill the field using a scheduled flow instead. But it took me less than three minutes to build, test, and schedule that DLRS rollup.) Schedule Your Work As noted above, we run this rollup nightly, an hour or two after the Data Processing Engine (DPE) for donor rollups runs. If this is the first time you’re hearing the phrase "data processing engine" or seeing the acronym "DPE," consider yourself lucky. I'll have to write about those sometime soon. The Short Version: a DPE definition is like a Flow that can collect, filter, and calculate, but it does the bulk of the work off-platform. Once you go through the new cloud setup steps, you'll have created a scheduled flow that runs the donation rollups DPE definition that Salesforce provided. This definition takes all your donation data, calculates the rollups for accounts, and then inserts donor gift summary records. Unfortunately, the DPE definition that Salesforce has provided so far has all kinds of problems, including getting some rollups wrong. (Oops.) And DPEs aren't Flows, particularly in the sense that nobody understands how to build or modify them. But what matters for the timing of this DLRS is that the DPE deletes all donor gift summaries and then inserts new ones, rather than doing an upsert (updating those that exist and inserting the new ones that are needed). So we have to make sure the DLRS runs daily and after the DPE is finished or else our new field will be blanked out for all records each night. (I assume that setting this DLRS to realtime mode would be a disaster when the DPE goes to insert all those donor gift summaries at one time.) The "Lookup Lookdown" is the Magic Now that we have a lookup field on Account that points us to a single DPS record, we have the option of adding any of the DGS fields to custom report types via lookup! (Great that we can do this. But it's still a pain in the butt to have to edit all of our custom report types.) We also now have the option of formula fields on Account that would span the lookup relationship. Those could allow us to put rollup fields on the page layout without using the R2D2 component [Not my favorite component.] or to calculate other things about an account's rolled-up/summarized donation information. Bam! Now a report that was simply impossible is unlocked. 🏆

Continuing our exploration of the new Nonprofit Cloud and the new Education Cloud, let's look at the Achilles heel of Industries solutions: the extension object. I noted in The Emperor’s New Clouds that extension objects are a workaround for the fact that the new clouds are built "on core." More specifically, extension objects are how building "on core" deals with adding fields that really ought to be added to standard (or "hero") objects like Account and Contact without having a managed package. I don't understand why Salesforce.org is so dead set against having a managed package for the new clouds. As we're going to see, not having fields where they belong is a critical flaw that makes the new clouds difficult (I would say nearly impossible) to use and increases the costs of implementation and upkeep exponentially. Even Financial Services Cloud has a managed package, so it's not like building on "the Industries model" requires that everything you put out be "on core." Recap on Extension Objects, or "Sidecar Objects" A quick reminder. Salesforce.org has chosen to build the new clouds "on core" and not have a managed package. That means that functionality relates to objects you can only see with special licensing that opens up access to Industries’ “standard” objects, some of which are new for the nonprofit clouds and others come from prior clouds like Financial Services, Health Cloud, and Public Sector. Any new fields referenced in new cloud functionality are on Industries objects because fields can’t be added to the “hero” objects that have been around forever. New fields can’t be placed on hero objects unless you publish a managed package, nor can picklist values be added to existing picklists. In those places where the engineers would have added a field on a hero object in the past in a managed package (say, in NPSP), they instead create an extension object. In my prior post, I used the analogy of an apartment and parking garage to explain these additional objects. I've also heard them called "sidecar objects," an analogy to adding additional passenger seating to a motorcycle or bike. I like that analogy because it makes it easy to start to point out the absurdity of extension objects. A sidecar is a nice addition to a motorcycle, it allows the passenger better visibility and allows the driver to see them during the ride, unlike riding behind the driver. In a pinch, I suppose, a sidecar would allow three passengers on a motorcycle. Plus they're useful for those that want to bring a dog along. (I don’t think dogs would be that good at riding pillion, which is one inoffensive term for riding tandem. I probably just taught you a new word. You’re welcome!) Of course, sidecars often take flak for being uncool. And they're murder on fuel efficiency. (This analogy is getting more and more apt!) Plus you very rarely see motorcycles with more than one sidecar. If you need multiple passengers that's what cars are for. Bloatware The other thing about extension objects is that they add massive bloat to the entity relationship diagram (ERD), the visual depiction of the tables in your database and their relationships to each other. That's no small problem! I don't particularly care that the diagram is a mess—though it is. But a data model that complicated is makes it harder to understand and internalize, harder to support, and nearly impossible to analyze using Salesforce's reports and dashboards. I headed this section "bloatware" because, indeed, there is object bloat going on within the new clouds. Now, I'm not opposed to complexity where needed. If you want to enable new features, you're going to have some complexity under the hood. But we want to do everything possible to hide the complexity for users. That makes it easier to adopt and stick with using Salesforce. So it’s a balance between complexity and functionality. I think it's clear that the fundraising model of the new clouds has failed in this respect. And it's happening in other areas as well, with the main culprit being the extension objects. Earlier, I wrote about Donor Gift Summary and Party Relationship Group. Now let me tell you about one more: Contact Profile. This one's so bad that I keep blocking it from my conscious mind. The Dumping Ground You know how sometimes people have more than one email address? Like a work email and a personal email. You’ve encountered this, I would imagine. Since Salesforce was originally a sales tool, there's only ever been a single standard Email field, which presumably was the work email of people at the accounts you were selling to. NPSP and EDA both added personal, work, and alternate email addresses, plus a Preferred Email field, and automation to move the preferred email address into the standard Email field. Sometimes even three isn't sufficient, so people make custom email fields to add to the mix. But building "on core" means Salesforce can't put extra fields on Contact (or on Person Account), so they can't have parity with NPSP in that sense. At the same time, sometimes it's important for organizations to know demographic information about their constituents. Beyond Gender, which is a standard field on Contact, sometimes they need to capture race/ethnicity, language spoken, veteran status, and more. These are fields that describe the person, so according to normal database design, they would belong on the Contact object. But no. The new clouds introduce Contact Profile, the sidecar object for storing demographic fields that clearly belong on the contact. Solves the problem, right? Wrong. Say a new client has just walked in the door. You're doing an intake with that person and you want to enter her name, birthdate, contact information, and demographics. Thanks to extension objects, within the standard Salesforce user interface, you’ll have to do this in two steps. Name, gender, address, and birthdate can all go on the Person Account. What to do with email addresses is ambiguous because there is one email field, but she just gave you three valid email options. Assuming multiple phone numbers (home, work, mobile, alternate) and multiple email addresses, those have to go on Contact Profile. Plus all the demographics have to go there as well. So you would have to create and save the Person Account, then click New in the Contact Profile related list, then enter the other pieces of data. How are we going to make that understandable for a new user? And even if they understand what data goes where, they're going to rightly hate all the extra clicks. Someone [that shall remain nameless] at Salesforce made the argument to me that it won't be common to want to create a contact and at the same time fill in their demographic details, so this complication doesn’t matter. I respectfully and very strongly disagree. Sure, in theory we could replace the new person account screen with a screen flow. Good luck ensuring users never find a "new contact" link in some obscure part of the platform user experience. And Yes, webforms like FormAssembly can make sure the data gets to the different objects for applications and the like. But the connector mapping is not so simple anymore, particularly because contact profiles are 1:1 with a contact. And these fixes make everything massively more complicated. “No filters for you!” But even if we get past the point of entering the new people into the system, we're not going to be able to do the things we need to do after that point. First of all, we can't use List Views as we would like. I'm a huge fan of list views. They're an easy way to give users some bulk update access without introducing an additional tool or having to build complicated automation. List views' power comes from filtering to find the records you need and then working with them in bulk. But you can't filter based on fields that aren't on the object whose tab you’re on! Say you wanted to quickly filter a list view for all your constituents that are veterans over 65 years old. Perhaps you're going to use the handy Add to Campaign button to put them in a campaign and then send them a list email. Or you just did a survey and then added a field for which branch of the military they served in and you want a user to use the list view for convenient bulk data entry. In the new cloud data model you can't do either of these things. On the Contacts tab you won’t be able to filter for veterans because that's data on contact profile. Nor could you add their military branch if you'd added that field on Contact Profile alongside the other demographic fields. But on the Contact Profile tab you don’t have the Add to Campaign button. You also don’t have access to the Birthdate field (it’s on Contact), so you couldn't filter for the over 65s. This particular very simple example you could theoretically solve on a report. First you’d have to build a custom report type that included Contact and Donor Profile, since the new clouds don’t come with any report types preinstalled for the new objects. But inline editing on reports is much less convenient than on list views, so updating the branches of service would be misery. Plus don't even get me started on the fact that these are contact profiles and would have to be a report type of Contacts with Contact Profiles. In the new clouds we’re using Person Accounts. Users should basically never even hear the word "contact" and should never interact directly with the contact object. So we're gonna confuse them with stuff like this. But next we're going to find that reporting is actually a huge problem. Reports Are Impossible Here is a very simple example based on a real client request: "I would like to make a report of all donations that came in last week from donors that have given more than $1,000 in their lifetime so that the executive director can send a personal thank you for the gift. I need columns for donor name, salutation, address, etc, as well as their total lifetime giving, gifts this year, gifts last year, and information about the gift that came last week." In Salesforce language, in the data model of the new clouds, the request is: Report Type: a custom report type (along the lines of Accounts with Gift Transactions) Filter: Transaction Completion Date = LAST WEEK Filter: Total Gifts Amount >= $1,000 Uh oh! Total Gifts Amount (the rollup that represents total lifetime giving for a donor) is neither on Account nor on Gift Transaction. It's on Donor Gift Summary, an extension object. Not a field available in this report type! And columns for Gifts This Year, and Gifts Last Year also aren't available either. Try as you might, there is no way to modify the custom report type Accounts with Gift Transactions to show fields on Donor Gift Summary. First of all, you can't add Donor Gift Summary as one of the objects in that report type. It's simply not choosable. And if you make a report type of Accounts with Donor Gift Summaries, you can't add Gift Transactions. If you're familiar with building custom report types, you might think about adding fields by lookup. Nope. Donor Gift Summary is child to Account—how would Salesforce know which of the child DGS records to pull from? There is no way to patiently explain to the custom report type builder, "there will only ever be a single DGS for any account, so use that one." For the same reason, you can't add formula fields on Account to pull this information up either. (Theoretically you could create rollup summary fields, but you’d run out of those pretty quickly.) We simply can't make this report. ⛔️ Now let's consider whether this is an unreasonable or unforeseeable reporting need? 🤔 No. In fact, I think something like it is very common, if not ubiquitous, in fundraising organizations. Putting fields on extension objects instead of where they really belong has just broken the most basic Salesforce analytics. 🤦🏻‍♂️ This gifts and rollups problem is just one example. Impossibilities in reporting turn up in multiple places in NPC/EdCloud. It's a critical issue. [I actually have come up with a method to be able to solve reporting like this. But it’s not a trivial fix on many levels. I’ll write about how to do this in my next post. But the idea that every fundraising org would have to build something like what I' going to write about is more than a little ridiculous. Just because I figured out how to solve it, doesn’t mean the problem isn't very very bad.] Late Edition: Merging Broken Too Do you sometimes find duplicate contacts in your org? (Or, for the new clouds, duplicate person accounts?) I bet you do. It's already enough of a pain to find them, merge them, and then prevent new ones from appearing. What if I told you that you won't be able to merge duplicates? It turns out that if there are 1:1 extension objects on both of the records you're trying to merge, the merge will fail! Imagine duplicate donors, probably caused when someone donated with their personal email the first time and their work a few months later. Both will have donor gift summaries (DGSs) storing the rollups about their donations. When you try to merge, the system is going to reparent both DGS records to the remaining parent account. But the DGS field that looks up to the account is DonorId and it's set to be unique. In the reparenting process they are both getting the same DonorId, which isn't allowed. So the merge fails. This failure will occur for any 1:1 extension objects, as far as I can tell. But let's assume the only thing both duplicates have are donor gift summaries. In that case you'll get an ugly error: As an experienced admin with access to the back end and a good deal of hard-earned obscure knowledge, I can figure out that a record Id starting with "6SX" is a Donor Gift Summary. Then I can delete one of the records and let the merge go through. Since rollups are generally recalculated over night, the remaining DGS will be inaccurate for up to 24 hours, but at least it will fix itself. Of course regular users aren't going to know what to do in this situation. And that was a relatively easy fix, because DGSs get recalculated each night. There are other extension objects that don't get calculated, let alone recalculated. (Such as Contact Profile.) For those, someone is going to have to manually compare the values to determine which to keep, transfer them to the record that will remain, delete the records that are no longer needed, and then do the merge. A Solution Only an Engineer Could Love Extension objects instead of putting fields on the object they describe just don't make sense. Nobody would ever build this way when customizing Salesforce. In fact, I think my example of the reporting problems makes it pretty clear that this would, in fact, be a wrong architecture choice. But with the decision already made that there will be no managed package, I trust that the software engineers at Salesforce have done the best they could. It just doesn’t actually fix anything.

OK, repeat after me: Salesforce is free like a puppy, not free like a beer. You get it, right? I mean, I named the blog after this concept, so clearly I think it’s important. Let’s look at what your nonprofit should actually budget to support your adoption and continued use of Salesforce. Now would be a good time to start up a spreadsheet to estimate your particular organization’s needs. 1. User Licenses The first thing to consider is probably the easiest to calculate: You’re going to need a license for every person that’s going to use the system. In most cases, that’s the number of employees at your organization or on the team(s) that are adopting the system. I very strongly recommend that you also use a separate license for each integration that you might connect to your system. Want new subscribers from Mailchimp to come into Salesforce as Contacts? Then give Mailchimp its own login. If you’re linking a fundraising platform like GiveLively or Classy to Salesforce, give that system its own dedicated user. That way you can distinguish between the integration doing things to your data and a particular user doing things. You’ll thank yourself later when strange data cleanliness issues are popping up. [Update 3/14/2023: Every org now gets 5 free integration users, with additional at just $30/year!] And don’t forget that if you get help from an outside consultant (like me), you’re going to need a license for that person as well. As a charitable organization (a 501c3 in the US tax code, or your country’s equivalent) you’re going to get ten licenses for free. The 11th license (and beyond) costs $432/user/year. [Update 11/8/2023: The price has gone up to $495.] So even if you have a good number of people that need to log into Salesforce, it’s a modest cost. 💰TL;DR in licenses: 10 full licenses for free 5 API-only licenses (integration users) for free (# of employees/contractors) – 10 = # of paid licenses # of paid licenses x $432 = cost per year 2. Implementation: Staff Expertise and Consulting This is the section where, unfortunately, I'm not going to be able to give you any hard numbers because it’s going to depend entirely on what you’re trying to do. First, I want to point out that implementing and then supporting Salesforce requires a commitment of money, time, and focus. You’re going to want to have someone on your staff that will be in charge of Salesforce, who spends at least a little bit of time thinking about the system as a system. Even if that mainly means that they liaise with someone outside contracted for support, it’s going to require some of their time and attention. Implementation in the first place is usually something to contract with a consultant for. Do you have to? No. There are fantastic resources available on Trailhead and help available when you have questions on the Trailblazer Community. I truly think it’s viable to self-implement if you have someone interested and competent who can spend some time on it. (But let’s not forget: that person’s time is a resource you’re devoting.) If you decide to use a consultant for your implementation, I still can’t give a solid number for what that is going to cost–it’s still 100% dependent on what you need. A simple implementation of the Nonprofit Success Pack for fundraising only and some light customization of picklist values, donation stages, etc, plus a little staff training can probably be had for under $8,000 and accomplished in under three months. Maybe. If you can find a consultant with relatively low rates that’s willing to take on a small project. A custom program management implementation is going to start around $15,000 and go up from there depending on the complexity of your program. And both of those numbers are assuming just implementation. Other than making sure you’re up and running with the new system, I’m not assuming there was any ongoing support within those numbers above. To bring it down to brass tacks, most consultants charge by the hour. Even those that try to do project-based billing are often working out what they think is the price based on some notion of how many hours they think a project will take and their hourly rates for the people involved. So what’s an hourly rate within the Salesforce ecosystem? I know this is going to surprise you to hear, but it depends. Below $100/hour is pretty rare at this point. There are probably plenty of people out there with not much experience willing to take a low rate. And there are people that do a little bit of consulting as a side-hustle and, therefore, are also willing to charge less. But experienced people charging under $100/hour for work with a US-based nonprofit are a rare breed. Consulting firms charge over $220-$250+/hour, last time I got any solid information. Some people give a discount for nonprofits compared to their full rates, but that may be what brings them down to the low $200s. Some independents are cheaper than consulting firms, but not all. There can be other factors that go into a final proposal price too, such as whether this will be the start of a long term relationship, or if a project fills a gap in work for a consultant. And also keep in mind that most consultants don’t straight up tell you their hourly rate. (Though it may not be very hard to figure it out when they give you a proposal.) At any price your mileage may vary. I think you should assume you’ll have to pay around $200/hour. If you’re based in an expensive city or think you want to work with a larger firm, I recommend you assume more like $250/hr. (Better to start high and be pleasantly surprised!) But in all but the simplest cases, I can’t even begin to give you a number of hours to assume. It’s a personal and business risk to do so, but I think price and salary transparency are good for society, so I’m going to put my own rates right here in black and white: In 2022 Kolodner.com’s full rate is $200/hour. I give a 20% discount to nonprofits ($160/hour). 💰TL;DR in consulting: It’s possible to self-implement if you have someone in place with the aptitude and able to put in the time. A simple NPSP “quick start” is probably $8,000. For more custom work, assume $200-$250/hour. Number of hours is entirely dependent on the kind of implementation. 3. Must-have Apps This can be confusing for organizations considering Salesforce, but the platform was designed from the beginning to support an ecosystem of related apps. As a result, there are some things you might expect “Salesforce out-of-the-box” to be able to do that you actually need to install an additional app to accomplish. The most important example here is mail merging. If you want to generate beautiful printed acknowledgement letters for each of your donors, you’re going to need to install a merge solution. You might think that’s annoying. Or you might come to appreciate the wide range of partners that have built solutions to extend Salesforce because they’re able to easily offer their products to you through the AppExchange. Not my place to judge. I’m just here to tell you what you should plan for. A Fundraising Platform I’ve got good news for you here: the price could be free! Of course you may choose to pay more for platforms with more or different features. I’m a big fan of GiveLively, which has no up-front costs, charges just the credit card processing fee, can let your donors cover fees, and has a free integration to Salesforce that’s easy to set up and works quite well. Salesforce.org released Elevate relatively recently which also only charges a fee based on transactions and, obviously, integrates with the Nonprofit Success Pack. Full-featured systems like Classy have a contract cost on top of credit card processing fees but offer more powerful features for peer-to-peer fundraising and the like. I know these contracts can be north of $10,000/year. And of course there are plenty of entrants between those two ends. It’s not my purpose here to tell you which fundraising platform to choose, just to remind you that you should consider whether you will have to pay for the platform, pay to integrate it to Salesforce (either a fee to the platform or the time for someone to set up the integration), or devote time to otherwise bringing the information into Salesorce. I suppose you should factor in $0-$10,000+ depending on the platform you’re going to choose. Apsona for Salesforce Describing all the things Apsona for Salesforce can do is way beyond the scope of this blog post. Suffice it to say that Apsona is a tool for easy import/export and manipulation of data within Salesforce. I consider Apsona such a useful tool that I actually require my clients to install it as part of a contract with Kolodner.com. I pretty much guarantee that having Apsona available will save enough consultant time to more than cover the cost of the app. Even if you’re not paying a consultant, the staff time you save with Apsona is going to be a bargain. Nonprofits pay just $435/year for three users. The smallest nonprofits (annual gross revenue not exceeding US $250,000) can actually get their Apsona license donated. Mail Merge Solution As noted above, if you are going to want to create documents based on your Salesforce data, this is something you’ll need an app for. (Note: Sending templated emails directly out of Salesforce is free. I’m only talking here about the need to generate Word docs or PDFs.) There are three main options in this space: Apsona Email and Document Merge, Nintex’s Drawloop, and Conga Composer. Nintex and Conga are generally more expensive than Apsona, not to mention having less-transparent pricing, so it’s hard for me to give a firm number here. Apsona would cost $300 for three users (on top of the base Apsona package that I just told you, above, I consider essential.) Drawloop and Conga cost more, particularly for volume document generation, but both have fans, so I’m not saying that cost should be the only factor in your consideration. Factor in at least $300-$500/year for mail merge, if you need it, plus some time for setup, training, and updating templates. Webform Integration Many organizations need a webform integration for collecting surveys and automatically putting that data into Salesforce. Sure, you could use Google Forms for free. But there’s no integration to Salesforce from a Google Form. (And Google Forms are ugly, IMHO.) There are quite a few webform providers that have integrations to Salesforce. Again, this post is not about comparing their relative merits. The point of mentioning this here is to remind you to budget for a form tool integration if you’re going to use one. I tend to recommend FormAssembly to my clients. At the Professional level, with nonprofit discount it’s about $700/year. Most of my clients get Premier ($1,600/year) to take advantage of the Salesforce Prefill Connector and do some really cool things with forms. If you think you’ll want a webform integration, start by budgeting about $1,000-$2,000 for the tool. And don’t forget to consider some consultant and/or staff time for learning the tool, building out forms (and their Salesforce connection), and ongoing upkeep! Some forms are relatively static (like a newsletter signup), but some are constantly changing (like an application form.) 💰TL;DR in apps: Fundraising Platform – $0 to $10,000 per year, plus credit card processing fees. Apsona for Salesforce – $375/year for three users, free to the smallest orgs. Mail Merge – $300-$500/year. Webforms – $1,000-$2,000/year plus setup and maintenance time. 4. Backup Solution I’ve got good news and bad news in this section. The good news is that Salesforce is extremely robust. You’re very unlikely to lose data because of a problem at the server or data center level. Plus there is a free weekly export service that you can enable to download a backup of all your data to store somewhere within your control. The bad news is that if you actually needed to restore your data from that weekly backup it could be an incredibly painful process. Plus the backups are only weekly and require someone to actually download and archive them each week. The other bad news is that the main cause of data loss (or corruption) is people. Backups don’t only protect you from data loss due to server malfunction, they also protect against people doing stuff. And it’s the rare nonprofit that doesn’t have people. Whether somebody accidentally changes data in small chunks or bulk updates, things can happen. Backup and restore systems are one way to recover from those things. There are a couple of options in the backup and restore space for Salesforce and none of them are cheap. To be fair, I think most organizations just live with the weekly export service and hope for the best. Sigh. Just because everyone’s doing it, that doesn’t make it a good idea. The two main services that I’ve priced for clients are Spanning and OwnBackup. Neither of them has transparent pricing. But for a nonprofit, I recall quotes starting at about $6,000/year from OwnBackup. Spanning is more reasonable: it seems to be around $40/user/year. Gearset also offers a backup solution which I haven’t had a chance to try. It’s an add-on to their Continuous Integration platform, so technically you’re paying for more than just backup and restore, but it might still be competitive pricewise. [UPDATED 3/8/2022 with more up-to-date Spanning pricing.] So, yeah. A backup and restore service that you hope you’ll never use might be your largest expense after the initial implementation. And it’s still a good idea. 💰TL;DR in backup: The free option really isn’t sufficient protection. Options start at least $40/user/year for nonprofits. You’re going to pay all that for something you hope to never use. Still probably worth paying for, like life insurance. 5. Ongoing Support Last, but certainly not least, you should be planning for the upkeep of your Salesforce instance, staff training and coaching, and updates and upgrades. The Salesforce platform is constantly growing and adding new features; likewise, your needs and circumstances are going to change over time. I strongly encourage you to think about growing someone internal who will devote a portion of their job to care-and-feeding of the system. I absolutely believe that any organization can grow this talent from within, as long as you have someone that is interested in the work and you give them sufficient time within their responsibilities. How much time to devote (what percentage of their job) is, of course, related to the complexity of your Salesforce setup and the parts of the organization it touches. If you can’t hire or grow a Salesforce administrator, you can contract with a consulting firm for ongoing support (often called “managed services”). Some consultants may sell a number of contracted hours for you to draw down over time. Others might let you simply pay for the time as you use it. I have set up contracts with several of my clients for a retainer where they get a certain number of hours per month at a discount compared to regular rates. Assume you’ll either have a staff member devoting between 25%-100% of their time or else contracted managed services from 10 hours/month or more. 💰TL;DR in ongoing support: At least one staff person devoting 25% or more of their time or else contracted managed services with a consultant. Bottom of the Bottom Line I literally started a blog to talk about how Salesforce is free like a puppy not free like a beer. You’re going to need to devote some resources to building, using, and maintaining a Salesforce instance, even if you never actually write a check to Salesforce directly.

In my introduction to the new clouds I mentioned that one of the potential benefits is the access to Lego-piece components (objects and functionality as well as page components) from other Industries solutions. I think it’s time to look at some of these and consider their benefits and pitfalls. Interaction Summaries Interaction summaries are an object created for Financial Services Cloud and subsequently used by several Industries products, including Health Cloud, Public Sector, and Nonprofit and Education Clouds. They were originally created, as I understand it, to allow for sensitive notes that could be shared and hidden based on a lot more criteria than Tasks can. Many consultants have spent many hours over the years either building special automation to handle privacy around tasks or building custom objects with their own sharing settings to hold sensitive notes. While this kind of privacy concern hasn’t come up for me very much in my client base, I can certainly understand the need for privacy around sensitive wealth management, therapy, and case management use cases. So score one for functionality that someone else built that the new clouds can take advantage of! But I’m actually not sure how to integrate interaction summaries into the rest of the platform, because of Tasks. (Which, to make things as clear as mud, are actually a record type of Activities. Tasks and Events are both Activities. But I'm only going to refer to Tasks.) Tasks have been around so long that it’s hard to move away from them. I have conversations all the time about how Tasks are incredibly frustrating for various reasons. (First culprit: the polymorphic fields: WhoId that could be either a contact or a lead and WhatId that could be just about any object. Second on the list: Task auto-archiving.) So often I want to just build a custom object and hide Tasks and Events! But we pretty much always come back around to how useful tasks are, and how integrated. If you send an email and want to log it, that’s going to be a Task (of a special EmailMessage type). Tasks show chronologically in the Activity Feed really nicely. And you can put Mopsy on the homepage so people see their open To Do items. You can check off tasks with one click. And so much more. So when I saw Interaction Summaries, my first question was "how do you decide what is a task and what is an interaction summary?" Of course you could try to draw the line around the sensitivity of the conversation. That has challenges around user training and adherence to business processes, but it could work. You could use Tasks only for future-date To Do items, checking it off but creating an interaction summary of what actually happened. I see challenges around making that work, but some could be solved with automation. I actually tried (and failed) to spark some discussion on the Partner Community around this question. No matter where you draw the line, though, I think you’re still going to come down on the side of having to use both objects. But then you end up with two objects holding notes from conversations, meetings, and discussions that don’t display together in a single list or activity feed. How frustrating is that? Enter an Industries component that it would appear someone thought solves this problem. (Spoiler alert: Nope.) Timeline I believe the Timeline component also originated with Financial Services Cloud, based on where I could find it in documentation. (Perhaps it was actually developed to deal with the challenge I just mentioned?) When I first saw this, I thought it was pretty exciting. As its name implies, it allows you to display records in a timeline view, similar to the Activity Feed of tasks, events, and emails. What’s cool about Timeline is you can create your own configuration and include multiple objects in the view. You can use it to get a time-based look at records related to the record you’re viewing. In the Health Cloud example, you’d see visits to the doctor, surgeries, screenings, prescription refills, etc, even if these were all different objects. (I’ve never looked into Health Cloud, so I have no idea. I just wanted to think about an example that wasn’t nonprofit-centric.) But I think you could find use cases on other objects, like showing records related to an opportunity, including customer support cases, sales calls, etc. It looks like something very similar to this component is available on the AppExchange, from Salesforce Labs. I’ve also used Time Warp, also from Salesforce Labs, which has a similar functionality but on the horizontal axis. So you don’t even have to be on the new clouds to get access to this kind of feature. But I saw this component in the Nonprofit Cloud trial org and I immediately could tell that whoever created that trial org template had not actually tried using it. The first thing I did on the component was click New and select Gift Transaction. That’s when I saw that the Timeline component doesn’t display the currency symbol next to a currency field! At first I thought maybe the trial org had a mistake in the Timeline configuration. But no amount of fiddling could fix it. I’ve since confirmed with the product engineers that it isn’t supported. Though the trial layout has an Email button in the Activity Launcher (upper middle of the page in the image two down), I also tried selecting New>Email Message on the Timeline component when I saw that. I was particularly curious how the Timeline would function as a total replacement for the Activity Feed. You see, the NPC trial does not have the activity feed anywhere on the page layout! Here’s where things get truly weird. When you click New Email in the Timeline, up pops—not the email composer widget we’re used to from the Activity Feed, but—this modal window: Umm, that’s not right. First of all, it didn’t pull in the email address of the person account I was on, nor does it have my email in the From line. And what’s with fields for HTML Body and Text Body? This feels…off. Oh, and there's no Send button, it says Save. Are you thinking this is not going to work? You’re correct, it’s not. The EmailMessage record you create with that modal is never going to send. That’s not how you create and send emails in Salesforce. But if you want to show emails in the Timeline component (which you set in the timeline configuration) you can’t turn off having New>Email Message. I’ve also noticed that Timeline is not as responsive as the Activity Feed. If you use its New button to create a record, it does not refresh automatically when you are done. I also don’t like that when you create a record from the Timeline the new record is created in a modal that covers most of the screen. This seems less functional than the way things work in the Activity Feed. What I really found inferior to the Activity Feed, though, is that you can’t see who a task is assigned to and you can’t just complete it by checking the box. There are ways you could improve what displays (such as a formula field that concatenates the assigned user and the subject) but this is yet one more thing that isn’t great out of the box. Am I nitpicking? I suppose a little bit. But this was developed for Financial Services Cloud. That’s an offering for which banks and wealth managers are paying through the nose. And Salesforce.org has included this in their new product for which they charge a significant premium. I expect a little more attention to detail for the price. Related Record Detail Display (R2D2) This is the one of two components that I know were actually built by Salesforce.org specifically for the new clouds. I so want to love a component that gets abbreviated R2D2. Let me start with what this thing does. As its name kinda’ implies, it’s used to display details (fields) from a related record to the one you’re viewing. It was specifically built to overcome the challenge that Salesforce.org has tied its own hands by eschewing a managed package and only building “on core.” As I explained before, since they can’t put fields on standard objects (like Account), the donation rollups that are so critical to fundraising analytics go on an "extension object" named Donor Gift Summary that’s child to Account. But if the fields aren't on Account, you can't put them on the account page layout. And you can't show them by a formula field or a dynamic form cross-object field either, because those require a lookup relationship. Donor Gift Summary is child to account, not looked up to from it. So the Related Record Detail Display was built by Salesforce.org in order to tell the page layout "I know they’re child records. But there will only ever be a single DGS for any account, so show fields from that one, please." It’s actually a clever engineering solution to the problem. Hat tip to the software engineers at Salesforce.org. It’s just… R2D2 is malfunctioning. First of all, the existence of R2D2 only solves the problem of displaying the rollup fields on an account page. It lets gift officers go to Joyce’s page and see that she’s given $250 this year. But seeing rollups for one person at a time doesn't scale. You need those fields in a report or as a list view filter or so many other places. I also find it strange that the R2D2 component gets its own layout. You have to build it painfully slowly in the Lightning App Builder, rather than taking any cues from the page layout of the Donor Gift Summary object or a configurable metadata item in Setup, like the Timeline component. And I found that a Lightning Record Page with an R2D2 on it won't deploy from sandbox to production, so after building the layout in the sandbox, I had to hand-build it again in production. That was fun. But even for the problem R2D2 was actually built for it's just…not good. Above, you can see them in the context of the whole page. Here’s a closer view: Do you notice how it doesn't look like the rest of Salesforce pages? -The section headers aren’t on grey backgrounds and aren’t collapsable. The fields are in boxes with the labels above, different from a Record Detail component. The inconsistencies are jarring. -Only three fields can show in a section, the rest are hidden behind Show More. (Users love extra clicks!) -If you click one of those Show More buttons and it shows additional fields, you can’t get the rest of the fields back without refreshing the whole page. -If there’s no Donor Gift Summary record, the component shows “No Data” in every field instead of blanks or something more elegant. -And sometimes this happens when you click Show More! These are all problems I noticed in the first few minutes I was in a trial org. R2D2 did not get a sufficient quality assurance check before it was published. Considering how quickly I saw these problems, I wonder what kind of QA happened at all. Again: Premium product at a price to match. We should demand better.

For years Person Accounts were a bit of a joke in the Salesforce community, something people liked to trot out as a feature you should avoid like the plague because this or that commonly-used feature would break if you enabled them. But at the same time, people would note that if you are architecting an instance that is literally only meant to work with people as individuals (not connected to “accounts” or “households” or the like) then person accounts are the official solution. So you can imagine the range of reactions when Salesforce.org let it be known that the new clouds would be based on person accounts. Besides this being a huge shift from the Household Account model of NPSP, there were a lot of people wondering what would happen if they suddenly have to use this feature that’s the butt of so many jokes. On the other hand, Financial Services Cloud has apparently been using person accounts for years, so I assume Salesforce.org figured if it was good enough for banks and wealth managers, it would work for nonprofits. Despite all my feelings about the new clouds, that actually seemed reasonable to me. But now I’m not so sure. I’ve had a couple of months to work in a real implementation of Education Cloud and poke around a new Nonprofit Cloud (NPC) trial and I’m starting to see that person accounts are a benefit and a curse. The Benefit OK, let’s start with the positive. By making every contact an account in their own right it seems like things are simpler in those instances where you mostly are concerned about someone as a person. If you aren’t concerned about who the other people in their household are, you don’t have the unnecessary creation of a household account, like you do in NPSP or EDA. That account never really bothered me (the NPSP triggers take care of creating it), but I know that some people found it confusing or annoying. (Some people also complained that the extra account could potentially impact storage usage or report speeds. Person accounts don’t solve either of these issues, though, because every person is both a contact and an account, so you might actually have more, not fewer, accounts in your org.) I actually worked on an implementation several years ago for a small law firm where I chose to use person accounts because each of their clients really was essentially a separate "account." For me it was a bit of a perspective shift not having a Contacts tab visible and having to choose Account>New when entering a new person. But that’s because I have longstanding habits. For the firm’s users it was all they knew of Salesforce and I don’t think they ever even considered it strange. The Curse The problem with person accounts, however, comes when you start trying to have relationships between people or between people and business/organization accounts. I know Financial Services Cloud works with exactly these data points, particularly for wealth management, using the same Industries objects that the new clouds use. Maybe in that industry the terminology is less of a barrier? But for those of us used to working with nonprofits, particularly used to doing so in Salesforce, the whole thing is just so much less understandable than NPSP. In NPSP there are three things we track: Relationships, which are between two people. (Example: Buffy’s mother is Joyce.) In most cases relationships should doubled, so we can understand the reciprocal relationship. (Joyce’s daughter is Buffy.) Affiliations, which are between a person and an organization. (Example: Buffy goes to Sunnydale High School.) These often have start and end dates, since people may change jobs, graduate from school, or come and go as volunteers for an organization. Households, which group people. (Example: The Summers Household: Joyce, Buffy, and Dawn.) Each of those NPSP objects is named exactly how we use it. When training users about these I never really have to explain more than the bullet points above. People just “get it.” In the person account model of the new clouds just the naming of relationships makes me want to cry: Contact Contact Relationships (CCRs) are between two people. Account Contact Relationships (ACRs) are between a person and a business account. Account Account Relationships (AARs) are between two business accounts. First of all, they’re all “relationships,” so it’s hard to distinguish. Second, saying or writing those object names is awful. So of course people are going to use abbreviations. But abbreviations just make things harder for new people to understand. I try to avoid abbreviations and jargon as much as I can. But I’d go bonkers saying and writing these out all the time! And it’s not like the full names really help to convey information. If you’re talking to a user that's new to Salesforce and is on person accounts, they basically never hear the word "contact" in a Salesforce context. All they create and work with are "accounts." Yet you’ll tell them they’re creating a "contact contact relationship." Are you kidding me? Also, given that these two people are both person accounts, why wouldn’t this just be an AAR (account account relationship)? I don't know. But you can't use AARs for that. I’ve been studying and working with this stuff for months and I still have trouble remembering what's what. If you want to group people into a household, that’s going to be some ACRs. Not clear on why they aren’t AARs, given each person in the household is an account and the household is also an account. But that's not how households are done. It gets worse. For some technical reason that I don’t understand, you can’t work with these things the way you'd expect in list views. (I really don’t understand all the moving parts here yet.) Not that I particularly want to put three list views on the page layout labeled Contact Contact Relationships, Account Contact Relationships, and Account Account Relationships. That would surely be a challenge for users (see above). But I definitely do want to put lists of relationships and of what-I-would-prefer-to-call-"affiliations" on the page. I think it might work to put related lists on the page. But Salesforce insists the right way is to use the "Actionable Relationship Center." I can’t remember why, but I recall some limitation around the related lists that is apparently insurmountable. Actionable Relationship Center (ARC) Salesforce is convinced this thing is super neat because it can display relationships in a hierarchical tree view and can group all three kinds of relationships together and can even show other objects once you configure it. OK, that’s interesting as a tool I might pull up to browse information about a donor or client. But if I want to quickly see that Joyce has two daughters when I go to her record, I want a list, not some kind of graphical tree. If I want to see that Buffy’s mom is Joyce and her sister is Dawn, I want a list. If I want to look at Buffy’s history of education and employment, I want a list. Lists are information dense, easy to sort (say, by start date) and re-sort, and nearly instant to comprehend. Also, if I’m looking for someone's relationships, I'm probably going to take in relationships to people very differently than I'm going to take in relationships to organizations. So they should be in separate places. Compare that to what you see in the ARC. 🤔 Also, when you want to actually take action with the actionable relationship center, such as creating a new relationship, you have to click the carat before you can click Add Relationship. Some people will never find that. (And it’s two clicks instead of one for everyone else.) Sure, in that image above, I can create a new Gift Commitment right in the ARC. But when I build my page layout for a gift officer, I'd make sure they could create a Gift Commitment quickly from a related list or a button, so color me unimpressed. By the way, I had to figure out how to configure the “Relationship Graph” to even show Contact Contact Relationships in the first place. The NPSP trial org has ARCs in it, but they are only configured to show Account Contact Relationships. 🤯 (See my prior post on why implementing and maintaining the new clouds is so much more expensive.) This Isn’t About Fundraising None of this post has anything to do with fundraising. These are the hassles of managing people and their relationships in the new clouds, regardless of what you are going to do. Many of my current clients don’t really do sophisticated fundraising (or don't do it on Salesforce...yet). I've built them custom program management solutions on top of NPSP because the relationship/affiliation management features are a great complement to the rest of the architecture we need. But if I were to try to build a similar architecture of custom program management for these clients on the new clouds I would also have to work around all these annoying ways that the relationships aren’t helping. Bottom Line Feels like a dodge to end this way, but the title says it all: I'm still skeptical of person accounts. I might end up using them, particularly if they become The Way of the Future. But so far, I'm not yet convinced.

Almost exactly one year ago I wrote about Salesforce.org’s new product announcements. To great fanfare they announced Nonprofit Cloud and Education Cloud, “next generation technology” that would be built “on core” to take advantage of...something something…marketing speak…marketing speak… At the time, I recommended that everyone sit tight because things were just announced and were not yet ready for Prime Time. The next few months validated my recommendation, as Salesforce announced that Nonprofit Cloud would initially launch with program management features but no fundraising functionality. (🤯) Then they accelerated getting fundraising launched because people were so confused. Now I’m back to update my recommendation and to give a lot more context. I’m particularly motivated to write about the new clouds again because I’ve seen that Salesforce is pushing these products hard. Partners that get referrals from Salesforce are almost being forced to implement using the new products. Organizations considering Salesforce are pushed to select the new products with subtle and not-so-subtle messages implying that they’ll be left behind if they do not. And people producing content about Salesforce (particularly partner “content marketing” blogs) are filling the Interwebs with articles like “Top Ten Benefits of The New Nonprofit Cloud.” They carefully avoid mentioning any pitfalls. Here’s my problem with all that: When it comes to people-tracking and fundraising—the most basic and important need for most organizations—the new clouds are broken. I mean seriously broken, as in: they don’t do the things you want them to do. And even some of the basic features that are included don’t work right. There: I said it out loud. 📣 There have been grumblings in private and behind closed doors, but most consultants are terrified of biting the hand that feeds them, even to the point of soft pedaling when they have to ask in the partner forums about a problem they’ve found. I’ve heard from partners that have been railroaded into implementing on the new clouds when they know a new client would save money (and time, and frustration) if they just stuck with NPSP. I'm going to make sure I go into [excruciating] detail about why I think this way so nobody can dismiss this as mere uninformed opinion. I've had a lot of conversations about this with people in a lot of different places within the ecosystem. Let me thank the many partners that have talked to me in private. All have asked that I keep their opinions quiet because they are afraid for their jobs and their companies' positions. But you know who you are if you're reading this, so Thank You. Especially thank you to 🥷. I've tried to give Salesforce chances to make these things right. And I still hope they might eventually pull it off. But it's clear that these products are going to be pretty broken for the foreseeable future; at least a year, probably quite a bit longer than that. And in some fundamental ways problems I'm pointing out can’t be fixed because of basic decisions that can’t be reversed. I can't recommend these new products for any organization doing fundraising. As a matter of fact, I can’t recommend against them strongly enough for any organization doing fundraising or tracking relationships between people. If you are about to embark on a new implementation, my general advice is that you should choose the Nonprofit Success Pack (NPSP) or the Education Data Architecture (EDA). Those have both existed for many years and are time-tested and user approved. And if you're already using Salesforce, just keep on doing what you're doing. There would be no benefit (and a massive amount of pain) to migrating. In fairness, I will temper that negative overview by saying that I hear the grant-making functionality is good. And I hear good things about human services case management in the new clouds. I don't have clients working in those areas, so I really can't say. But I can say that if you are also doing fundraising, for example, you're going to have a world of pain. And I can say very confidently that if you are a small or medium-sized organization, the new clouds are not for you. The new clouds are viable only if you have expert in-house Salesforce support combined with significant and permanently ongoing partner support. I’ve spoken to a lot of people who are smarter than I am and have more experience than I have in consulting, in Salesforce, and in the various product offerings. I’ve asked them to show me what I’m missing or why I should be less hard on these products. Most of them straight-up give me kudos for voicing what they feel they can’t say out loud. Should we get into the details? Background: Nomenclature For starters, there are actually two new products, Nonprofit Cloud and Education Cloud. For simplicity's sake, I'm usually going to refer to "the new clouds" collectively. But I might sometimes say “EdCloud” or, for Nonprofit Cloud, “NPC” or “New NPC.” The “new” part is meant to distinguish that I’m talking about the products introduced in 2023. Before the 2023 announcement Salesforce.org had started referring to their prior offerings as “Nonprofit Cloud” and “Education Cloud,” when they were bundling NPSP or EDA with some other paid products, like Accounting Subledger. Yes, that was confusing at the time. (And now it’s even more confusing.) What you need to know is that what we call "the New Clouds" are entirely different from what existed before. If I mention one cloud or the other by name, it’s going to just be for the sake of variety. Actual functionality I’m discussing is common to both products. That’s one of the interesting things about Salesforce.org’s choice to move these products “on core.” They are using the model of Salesforce Industries rather than releasing a managed package. Industries components have been described to me like Lego bricks, where you can choose any bricks that will help you build what you want and they are all compatible. So when it comes to the new clouds, when Salesforce released “fundraising” functionality, even though they’ve called it “advancement” for the education market, it’s not just something that works similarly. It’s exactly the same thing in NPC and EdCloud, with the same objects and fields, the same processes, and even the same documentation. Or, more accurately, as of the time of this writing, if you look for documentation for how to set up and use Advancement in the EdCloud docs, it’s not there. You have to go to the Nonprofit Cloud docs and find the section on Fundraising. Yes, that is a source of confusion and frustration. That frustration aside, the promise of the Industries model is that developments in things like Health Cloud, Financial Services Cloud, and Public Sector Cloud can be used by nonprofits plug-and-play. That’s potentially interesting. In fact, the one scarce item of praise I’ve heard for the new clouds is that the case management features that Nonprofit Cloud has lifted straight from Public Sector Cloud are apparently quite nice. (I truly can’t speak to that because I don’t have clients working in that space. But the person that said it to me is very smart and very experienced.) But keep reading because I think this exact benefit from the Industries model is also the root of the problem. The “Core” of the Problem Here’s the thing: By choosing to build “on core,” Salesforce.org made the decision that all objects and fields they use in the new clouds will be standard fields. They are not putting out a managed package that has objects and fields preceded by a namespace and followed by “__c.” When it comes to objects specific to the new clouds, that’s neither here nor there. It really doesn’t matter if there is a GiftTransaction object or a nonprofitcloud_Gift_Transaction__c object. And it doesn’t matter if the fields on that object look like Total_Amount__c or just TotalAmount. What matters is that building on core means it's very difficult (essentially impossible) to add fields to core standard objects ( the "Hero Objects," like Contact, Account, Opportunity, Case, etc.). If you want a field in your Industries solution, you pretty much can only add it to an Industries object. [Edit added afternoon 3/13/2023: End user admins can add custom fields on any object, exactly as we are used to doing. I'm saying that Salesforce won't put fields on those objects.] Think about that for a moment. No fields added to standard objects. Do you believe that people might have more than one email address that you would need to track? Standard Salesforce has just one Email field, on Contact. In 1999, in a sales CRM, that’s all you needed: it was their work email. But nonprofits often want at least work and personal email. NPSP includes work, personal, and alternate email fields, plus Preferred Email to know which to use. In Nonprofit Cloud Salesforce can’t deliver these fields. (At least, not on Contact, where they really belong.) I’m not entirely clear on why not, but it seems to essentially be that putting a field on Contact would actually put it there for every org everywhere, because it’s a standard object. (That’s what “standard” means.) Users that didn’t have the permission set license for Fundraising perhaps couldn't see the field, but it would be there in the background. Mainly, I don't understand why Salesforce is so dead-set against having a managed package to deliver those fields. We're going to need them. I don't get the impression that building on core and refusing to have a managed package (even of just fields) was an engineering-led decision. I think someone in marketing, or sales, or other executive leadership made that call. I think it was a poor choice that the new clouds are saddled with, presumably permanently. Think, now, about the implications of not being able to add fields to core standard objects the way you would with a managed package. NPC and EdCloud, of course, are fundamentally about tracking people. So they’re going to use Contacts and Accounts. (Actually, they use both together, in the form of PersonAccounts, which I’ll talk about another day.) Let’s think of probably the most basic nonprofit requirement: donation rollups. You want to be able to see how much a particular person has given this year, last year, over their lifetime, etc. The fields in which you would put those numbers naturally belong on the contact (or account) that gave the money. But you can’t put a new field on Contact or Account. The other thing many organizations want to do is group their donors into households. For years we’ve done this in NPSP and EDA using a Household Account record type (a jargony way of saying “an account that we designate as being a household in order to group a family of contacts in it"). But in the new clouds Salesforce can’t put a field on Account to designate it as a household. They can’t even add a picklist value to the Type field for “Household.” They definitely can’t create a record type Household Account. This seems quite limiting. And it is. As far as I can tell, the other industry clouds also faced this problem. The solution they came up with is called “extension objects.” They’re not a good solution. Extension Objects: A Solution that is a Problem The idea behind an extension object is that you make a child object to hold the fields you would have preferred to put on the parent object. Even though it’s a child object, you ensure that there can be only one for each parent, enforcing uniqueness on the field that looks up to the parent. Now you’ve “extended” the first object because this new object is locked to it 1:1, so fields on either directly describe both. Let’s use a condo in an apartment building as an analogy. You can’t actually add a parking space to each apartment. Driving the car into the elevator and along the hallway is impractical. So you build a garage underneath the building and number each space with the exact same number as one of the apartments. Perhaps those spaces are actually a little bigger than a car, so you add a fenced storage unit along with it. You have now “extended” the apartment to include a parking space and extra storage. But the apartment is still distinct from the parking space and storage locker. In fact, the owner of apartment 14J might not have a car, so she might sell the space. Now it is no longer connected to apartment 14J. If you want to buy apartment 14J and park your car, you may need to purchase two things. (And then you might live in 14J but park in 3L.) So while the apartments in your building are extended to include parking, there is some nuance around how you actually think about the apartment and the parking space—they are not one thing. The new clouds have this same problem around nuance. Let’s look at two examples. Donor Gift Summaries (DGS) I think the easiest area for most people to think about extension objects is around donor rollups. Every organization that does fundraising wants to be able to see how much a donor gave this year, last year, the year before, over their lifetime, and dozens of other metrics like these. In the Nonprofit Success Pack these are all rolled up to fields on the contact. In new Nonprofit Cloud and new Education Cloud these metrics live on their own object, an extension object called Donor Gift Summaries, or DGS. Donor Gift Summaries have a Master-Detail (Unique) relationship field to Account (because people are Person Accounts) called Donor. Leaving aside how the rollups on Donor Gift Summaries get filled and how broken they are (a topic of a future post), it’s on the Donor Gift Summary record that you find fields for Total Gifts, Gifts This Year, Gifts Last Year, etc. Party Relationship Groups (PRG) This example is far harder to get your head around, in my opinion. Above, I mentioned needing fields to designate that certain accounts are households and others are business accounts. For this, the new clouds have an extension object called Party Relationship Group, or PRG. This object is also Master-Detail (Unique) to Account. (Why are these named “party relationship group” instead of something meaningful like “account profile”? I have no idea. PRGs come from Financial Services Cloud. I think one of the main reasons party relationship groups are so hard to understand, honestly, is the name.) To make a household account in the new clouds, you create an account (a “business account” as opposed to a person account) and give it a party relationship group that designates it a household. Clear as mud, right? At first glance you might think, "this is clunky but potentially manageable. It’s going to be confusing, perhaps, for new users. But maybe with some clever engineering we can hide the extension object from users so they don’t have to think about it?" That sounds like a good theory, but it doesn’t jibe with the ways that Salesforce works. No Report Types (!?!) First of all, let me note that there are all these new objects in the new clouds but there are no report types to go with them. So out of the box you can enter gift transactions (donations) but you can’t make a report that includes the gift transaction object because when you go to select a report type (that crucial first step in reports!) there are none that include that object. This “standard” object doesn’t even come with the kind of “custom standard” report type that magically is created whenever you create a custom object. This kind of built-in analytics is part of what makes Salesforce such a powerful platform. Seems odd not to have it out-of-the-box in the new clouds. I hear that Salesforce.org is embarrassed about this omission and is trying to fight the Salesforce bureaucracy to be able to ship report types to customers in the future. But as of this writing, your new cloud instance does not come with report types for any of the “standard” objects that make up these products. Again: I don't understand the avoidance of a managed package. OK, so then we’ll make some custom report types. That’s not the end of the world. (But it makes implementation on the new clouds take longer than it did for NPSP or EDA. And more time in implementation means more cost, since consultants generally charge by the hour.) But if every organization is making their own custom report types, that means that things won’t be standard across organizations. That makes it harder to collaborate with other organizations and to train users (or let them bring their knowledge from a previous job). Pro Tip: By the way, new cloud "free trial" orgs actually do have report types in them, and even some example reports. (But “base trials” do not.) So if you have a tool that can allow you to deploy metadata across orgs (such as Copado or Gearset, or you could even do it with CumulusCI) there’s nothing to stop you from creating a trial and then deploying those example reports and report types to your production instance. It sure saves time over building them by hand! I think this is a lovely workaround. But it is a workaround we had to come up with because Salesforce.org has not provided the tools we need in the first place. But at the heart of the matter: custom report types actually can’t solve the problems created by the extension objects. In fact, I'm going to have to write a whole additional post about the problems of extension objects. Coming soon. “Thanks, Industry Cloud.” Last point, but certainly not least: implementing the new clouds is a lot more expensive. It’s my understanding that this, too, comes from the Industries model. Sales Cloud, Service Cloud, and even the Nonprofit Success Pack basically are usable “out of the box.” If you get yourself provisioned with a new Salesforce instance of one of those products, you can start loading in your accounts and contacts and start doing your work right away. Sure, there are a handful of initial things you want to turn on, set up, or customize. But you could put that off and try out the system for a bit, customizing later. Or you could spend just a few minutes and then you’re ready to go. It’s like getting a meal at a fancy restaurant. Getting into a new Industries cloud is more like cooking a really fancy dinner from scratch. A fresh NPC instance is a nice box of ingredients. There are recipes included (of varying quality and reliability). But the final product is going to vary with the cooking skills of the chef. Also, you might burn one or more dishes. This is not specific to NPC and EdCloud. As far as I can tell, this is how Health Cloud, Financial Services Cloud, and all the rest of the Industries clouds work. They’re premised on the assumption that implementation will be done by an experienced consulting partner and strongly customized for each org before any users get into the system. They're expensive, premium solutions sold to deep-pocketed industry customers. I don’t really have a problem with strong customization of Salesforce to match your org’s needs—it is, after all, what I do for a living. But this is different from the assumptions behind NPSP. I don’t think any organization could self-implement on the new clouds. For the tens of thousands of nonprofits that use Salesforce because it's "free," this is not going to be a good fit. And that’s only part of how the new clouds cost more. More Expensive In All The Ways 💰 Don’t forget that the new clouds have higher license costs. I’ve written extensively about license pricing in the past (among others, here and here), so I won’t belabor it here. New cloud licenses cost $720/user/year, which is more than 45% more expensive for nonprofits than Sales Cloud licenses. And you’re not going to be able to economize using Platform licenses as easily, either. (Platform licensed users will not be able to access any of the new cloud objects.) Licensing is complicated, so consider your own use case for cost subtleties, particularly if you are considering NPSP plus one of the paid add-ons. But in the vast majority of cases, NPC will cost more than NPSP for licensing. But the real gotcha is in implementation. I’ve asked around a bit. For now, people seem to think it’s taking at least 50% more hours to implement on the new clouds. Even if only half of that additional cost gets passed on to the client, that’s a lot more expensive. (And if the consultancy is absorbing the other half of the additional cost, it’s more expensive and less profitable. 💸) The gap is going to shrink as more consultants build familiarity with the new clouds and consultancies develop processes to save time in the implementations. But the new clouds have a suite of new tools to learn, like industries common components and data processing engine, and fundamentally more complex data models. They have fewer things that work out-of-the-box, and more “post-install setup steps.” They will always take longer/cost more to implement. Every implementation is different, of course, and some are much larger than others. But where you could do a “quick start” implementation of NPSP for five to eight thousand dollars or even self-implement for “free” (not counting internal staff time), I think the minimum implementation on the new clouds is going to run into the [plural] tens of thousands of dollars. And I believe it’s going to be more expensive to use and maintain the new clouds as well. First of all, training for users is going to take a lot more effort—these things are just harder to understand. There are more “moving parts” and you can’t really figure out how to work within the system until you have some sense of what goes where. (See also: Extension Objects.) The Salesforce ecosystem is full of stories of accidental admins (including me), who started as power users and transitioned into running the system. The first step is often being the office resource that understands reports and dashboards. It’s a much higher bar to learn reports in the new clouds, as my example above illustrates. Is it a bar people can clear? Yes, for sure. But I think that nonprofits on the new clouds will need generally more-experienced admins, so that’s going to cost more to hire and retain. And managed service support for a more complex system is going to cost more as well, just because it takes more time to do everything. I’ll Tell You How I Really Feel Someone recently made a crack that she was “still in the ‘anger’ phase of her grief process over working with the new clouds” when we found yet another major bug in the EdCloud implementation we’re working on together. I might be at “bargaining,” with all the work I’m putting into workarounds and architecture to solve the gaps and failures. But mostly I’m aggrieved that these products are so terrible. I want to be clear that my argument is not with Salesforce's engineering team, it's with the executives that made the choice to move to Industries and build "on core." The same people with power over the price increase on all nonprofits. They seem to only care about profits, which come from the big well-resourced organizations not the small nonprofits. And they made the mistake of not having a managed package, which imposes constraints that appear to be insurmountable. The product managers trying to build a solution under those constraints really do take the needs of even small nonprofits to heart. But working with clearly insufficient resources for the job (following last year's layoffs) and probably under unreasonable deadlines set for sales and marketing reasons, the products have been released insufficiently tested and lacking in key features. I’ve got a lot more topics surrounding the new clouds that I need to cover. Watch this space for several more installments in this saga.

I don’t think you should pay for Premier Success. Look, this is no AppleCare. When you open a case with Salesforce Support you’re not going to get the kind of fast, knowledgeable, and personal service that we expect from the best consumer brands. You’re also not going to get an experience as bad as some support we’ve all experienced. (I’m looking at you, Internet Service Provider monopolies. 😠) And credit where credit is due: Salesforce Support has gotten better in the last several years. Nonetheless. You don't need Premier Success. Premier Success is something that AEs suggest because they’ll make a fat commission on the sale. Even more, they use premier support to try to sell you Unlimited Edition (which you definitely don’t need.) The Cost You can purchase Premier support a la carte, it costs 30% of the net licensing cost of your org. For the purposes of that calculation, your free licenses count at their normal price ($495), not as zero dollars. So that means the minimum cost of Premier Success is $1,485. If you have more than the P10 licenses, it goes up from there. The Features The .Org pricing sheet lists features of Premier Success as, “Additional Expert Help, Adoption Guidance, Coaching and Live Support.” It doesn’t explain what they actually mean! So I asked around a bit. Accelerators, which are a menu of specific engagements regarding particular features. Some are live coaching and others are webinars. There are some nonprofit specific topics available. These could be very useful if you are new and would like help learning to do a particular thing. Because some include access to a live person, you can ask questions and perhaps learn in a different way than just through Trailhead or videos. On the other hand, I’ve heard those described as Trailhead modules that someone guided you through. Plus the person assigned to you might not have real world experience to back up their assistance. Accelerators surely aren’t going to be worthwhile if you have an experienced admin around, but they might help speed you along the learning curve. Developer Support, which the standard support tier does not include. You need to pair this support with your own developer (or at least experienced admin) resource, though. I don’t think the support agent is going to rewrite your code, much less deploy the fixed code for you. They can help debug and suggest solutions, but you still need someone that will understand what they’re saying and be able to implement those solutions. Faster Response Time and Priority. This is perhaps the main selling point. I think Premier gets you responses within 24 hours and you’ll be escalated to a higher tier of agent, plus they’re available 24/7/365. So once you go to the trouble of opening the case, at least you get some movement quickly and should get more knowledgeable responses. Premier Success customers are prioritized when backlogs are high and also have access to chat. 25% discount for Trailhead Academy trainings. Those live trainings are expensive! If your org is actually going to take advantage of them, this discount alone could be worth the cost of admission. But very few small nonprofits are going to send someone to a multi-day live course. (Most organizations of the size I work with barely manage to allocate professional development budgets at all. Just registration and the day off to go to a community conference can be a struggle.) But I've Already Got It If you're reading this and realize that your org has already paid for Premier Support a la carte or as part of Unlimited Edition, I feel your pain. You are not going to be able to modify your contract mid year, so that cost is sunk. (Remember to request to remove it when Salesforce sends your your next invoice.) So while you're paying for it, take advantage of the benefits! As I said above, I hear Accelerators can be useful. Access as many of them as you can. (The rules on how many you can use or how frequently have shifted over time, so I'm not sure what they are right now.) Look especially for the ones that are listed as Individual Sessions. You can use those like mini consulting engagements without additional cost. If you can swing it, sign up for a Trailhead Academy course. Spend a week getting live instructor-led training and emerge ready to take your admin certification. A Case Is Still No Fun Case response time is improved, but nothing happens from Support until you actually open a Case. That’s already a heavy lift. The case creation flow is detailed and time-consuming. And it’s strongly centered around the idea of writing out the Steps to Reproduce, like you’re detailing a bug or trying to figure out automations that are doing unexpected things. Opening a Case is not the right route to learn new areas of functionality or get advice about the best ways to do things. This is where the amazing Salesforce Community is your superpower. Post a question to the Trailblazer community, ask in Ohana Slack, go to a user group meeting, or find a knowledgeable volunteer. You’ll get much faster responses. Not Personalized Here’s the thing, too: the support agents don’t know your org. You could have all kinds of customizations, from page layouts to automation—not to mention policies, procedures, and terminology—that they know nothing about. So the support they’re going to be equipped to give will fall into two categories: They can point you to general resources. I’m pretty sure that’s all you would get in the “adoption guidance” and “coaching” categories. They can help troubleshoot a specific issue, at least to narrow it down to the source. But you need someone that knows the context to make the final fix. This is the major difference between having faster access to Support and having a skilled internal Salesforce admin or a trusted consultant that you can call. Your internal admin or a consultant is going to get to know your org and will give you support in that context. And don’t even get me started on getting routed to a support agent that understands the Nonprofit Success Pack (NPSP) or new Nonprofit Cloud, or even the nonprofit industry in the first place… What is Support For? I don’t mean to bash Salesforce Support at all. As I said above, I have been pleasantly impressed with improvements over the last couple of years. Every so often I still have to open a case to try to figure out something obscure and I’ve found agents to be helpful and (usually) knowledgeable. But I don’t open a case until it’s absolutely unavoidable. And when I do so, I am extremely careful to document complete steps to reproduce the issue, include screenshots, link to specific records, and generally snow them under with detail in the initial description so that I won’t have to waste time answering questions. (I still sometimes get a first response that indicates they didn’t read what I’ve written, but then I can politely point them back to my description to try to move things along.) What I do not use a case for is to try to figure out how a feature works or to get advice about best practices. That’s not in the support wheelhouse. I consider support cases to be only for things a relatively-seasoned Salesforce admin can’t solve even after raising the issue to other smart people in the community. Basically, when I open a case, I suspect there might be an honest-to-goodness bug. 🪲 Bottom Line You probably do not need Premier Success. Faster response times are nice, but not worth the cost. As a clever friend of mine said, “Premier support will still ask you what the issue is without reading your case—they'll just ask it sooner than the regular support queue would.” Take the money you would spend on Premier Success and put it toward your admin going to one or more Dreamin’ events!

A few months ago I found out about a Salesforce default change from Winter '21. (Yes, I guess I was late to the party learning about a change from Winter '21. But I've seen several posts from others just starting to figure things out. So...) Starting with that update, users in new orgs will have their default email encoding set to UTF-8, otherwise known as "unicode.". Prior to that the default was ISO-8859-1 (aka Latin1). That's good, because unicode is a much broader standard, with support for almost all possible characters. (Plus it includes emoji—and we know I love me some emoji! 😘) If you ever wondered why an outbound email from Salesforce did something strange, such as drop emoji that you know you put in the title, this is probably the culprit. (Yes, that's exactly how I started digging into this.) Check Yourself Before You Wreck Yourself Check your own user setting to see if you're still in ISO-8859 (Personal Settings > My Personal Info > Language & Timezone > Email Encoding) and, if you are, Step 1 is to set that to Unicode (UTF-8). You won't regret this change, I promise. Now have fun sending an email replete with emoji! 🏴‍☠️ Future Proof Your Org Admins reading this blog should probably consider fixing the problem for everyone. Go to Setup>Users and check the email encoding of all your users. If your org is more than a couple of years old, you probably have a lot of users that are still on Latin1. You can—and I would argue should—just switch them all in bulk. I really don't think there is any downside. UTF-8 is backwards-compatible with ASCII and nearly any email client being used today will have no trouble with it. Options for updating the users in bulk depend on what tools you have available. If you've got Apsona it will take you longer to read this article than to make the fix. You can also do this via Dataloader.io or other tools. Now For The Cool Part I haven't been able to verify this with documentation, but I think that you only have to make this change and not worry about it going forward. As far as I can tell, once you've set users to UTF-8, when you go to create a new user, they are going to default to UTF-8. (Or maybe it's that all new users already started defaulting to UTF-8 with Winter '21 and I just didn't notice that until after I had set existing users to UTF-8? But I could swear I had newer users created in client orgs that were still on Latin1. I even had set myself a task to build a flow for new users. But before I built it I started noticing that new users were defaulting to unicode... 🤷🏻) But the bottom line is that you don't have to remember and you don't have to build a flow to keep things in line. So hooray for that! But make sure you update all those existing users.

I sometimes wonder if people are using the things I build. I can tell if they're filling out fields, of course, or creating records of a new object. But many of the things I build only happen in the background. They're flows that automate a process to speed it up or make it more efficient. And the impact of those is a whole lot harder to measure. At the same time, it can be tricky to build, test, and debug automations even with the great improvements to Flow Builder. Sometimes I have trouble visualizing what is happening within the steps of a flow. I need to see the results "physically" represented so I can track where parts are moving. In a screen flow it's easy enough to add interstitial screens that just show me the values of variables or display a message to let me know where I am in the process map. But you can't do that in record triggered flows. They run invisibly while you're working in the user interface, doing their magic before or during the save of a record. So I often need some other way to keep track of what is going on. At times I've used Chatter posts, either on a created/updated record or tagged to a special Chatter Group for aggregating such posts. In a pinch I've also created Tasks, since they're easy to create and even to relate to records that are being updated. Both of those methods work. I sometimes even still go that route if I just need something in the moment. But they're really only good for the debugging use case. They're not so good if you want to actually be able to report on how often a flow has fired or to capture structured data into fields for sorting and analysis. Introducing FlowLog So I built a custom object and I gave it the super creative name of "FlowLog." Because, well, I use it for logging Flows. Besides the flow name of the flow, I created fields for the Version (which, to be honest, I rarely use), the Step, and Notes. I decided to let FlowLogs be auto-numbered because that would make them easy to sort in order of creation, even when several might be created during the same instant. Now that I have an object to store my logs, it's very simple to have a Create Record step that quickly drops in one of these records at any point in a flow. Easier with a Subflow I've actually made FlowLog even easier to use by creating an autolaunched flow. Then I can drop that in as a subflow in any other flows I'm building. In another of my brilliant feats of creative naming, I call that flow FlowLog. No brilliant magic to that subflow. It can accept variables for the flow name, the step, and the notes, which it uses to assign a FlowLog record variable. Then it inserts that FlowLog record. (I could have just done it as a single Create Records step, but I'm used to doing the assignment before the record insertion.) Then I can put the subflow in multiple places within a flow, either logging steps along the path or handing it different variables to indicate that it's firing at different ends of decision paths. Don't Repeat Myself I don't want to have to build this each time I need it for a new client. Not that creating a custom object with four fields on it takes more than a couple of minutes. (Though creating each of those fields takes more clicks than it ought to. Ahem.) But recreating the subflow would also take a moment. No, the way to go here is to store my work so I can install it multiple times. There are three main ways I could accomplish this: Unmanaged Package I could save this object and flow as an unmanaged package in a dev org and then install it in client's orgs. You can modify the elements of an unmanaged package in your instance all you want—that's what "unmanaged" means—so this is functionally the same as building the elements in the client org. The only thing that bothers me about an unmanaged package is that it shows up as an entry in Setup>Installed Packages. An admin might not recognize that this isn't a commercial managed package. I want this to be metadata "owned" by the org that they're free to change/remove/etc. And if that's the case, then a listing in Installed Packages just seems like clutter, to me. Metadata Deployment If you build in a sandbox, you can deploy your changed metadata to production or other sandboxes using Change Sets. But those deployments have to be between related instances. (Production and the sandboxes of that production instance.) I, of course, have not built FlowLog in a client's sandbox. But there are tools that can do a cross-org deployment, including Copado and Gearset. I use Copado Essentials for deployments all the time—it's much faster than change sets. So I could store FlowLog in a dev org and then use Copado to deploy it somewhere else. The benefit to installing this way is that the object and the flow look like they entirely belong to the client's org, as though they were built in a sandbox using clicks and then deployed to production, the same as any other objects or fields. There's no practical difference here from the unmanaged package and we've avoided that confusing entry in Installed Packages. Code Repository (A "repo" for those in the know. 😉) There's one final option, which is to store my metadata in a code repository, like GitHub, and then push the metadata to a connected org using SalesforceDX or CumulusCI (CCI). In terms of the function within a client org this option is no better nor worse than the cross-org deployment. The elements still end up in the client org looking as though they were built there. The benefit to storing what I build in a code repository is that I could share it with others and collaborate on further development. Or even for my own purposes, it's just nice to be able to quickly spin up clean scratch orgs to work in and then save my progress or throw out work that was a dead end. (Plus I have the metadata stored on GitHub and easy to back up on my computer if I should somehow lose access to my dev org.) To use this method I had to learn the Salesforce command line tools and learn to use GitHub Desktop and VisualStudio Code, all of which took me outside my declarative comfort zone. (And I mostly need a cheat sheet to remember the handful of commands I even understand how to use.) But there's a very good Trailhead trail that takes you step-by-step to install CCI and understand some of the benefits of using it. Try This At Home Nothing I've described here is a great innovation. This is just a good idea that I think anyone can use. You can build your own FlowLog object exactly like mine if you want to. In fact, I encourage it! (Heck—I don't even mind if you use the same name!) I suppose I could make my GitHub repo public and you could just grab it right from there. But that seems like it's spoonfeeding you too much. I've taught you to fish. 🎣 Now go get a little practice behind the Setup gear. ⚙️

I've published several times on the How I Solved This series of the Salesforce Admins Blog, including the first of the series and the first video HIST post. But they took a pause on posts of that kind for a while, so I've got what I think is a clever solution using Flow that I'll just have to publish myself! Background I work with a great little organization called For Pete's Sake Take a Break From Cancer Foundation. They work to give cancer patients and their families a trip together to get some respite from the stress of regular life and the disease and just enjoy each others company. When For Pete's Sake (FPS) gets an inquiry about a patient that might benefit from a respite trip, this data comes into Salesforce as a Lead. Besides the standard Lead fields, which are used for the patient's name, phone, email, etc, there are custom fields to hold the names of other people that will be part of the patient's engagement with FPS, including the nominating healthcare provider, the person that inquired about a respite (for their friend, spouse, family member, etc), the primary caregiver, spouse, children, etc. When the lead gets converted the patient will become a contact, of course, and all of those other fields will either become contacts in their own right or be matched to existing contacts already in Salesforce. But the lead conversion is meant to only happen at the point that the nomination for the patient is complete. Nominations must come from a doctor that has received onboarding from FPS and the nomination form includes various parts, such as certifications that the patient meets the program guidelines. So all that is by way of pointing out that FPS might get an inquiry (that creates a lead) but have a lot of follow-up work before lead conversion. In today's case FPS program staff might need to reach out to the "inquirer" if the initial inquiry didn't have all the necessary information. The bulk of this follow-up work is going to be done by email, as you can imagine. And it would be best if we tracked those emails in Salesforce so that we can see the progress right on the lead. But here's where things get interesting: the lead is the patient. But the emails FPS program staff needs to send are to the Inquirer. That person is almost certainly not in Salesforce (yet). When she needed to email the inquirer, FPS's mission coordinator, Pam, used the email composer, but this challenge initially was generated when Pam asked me if there was a way that when she opened the composer it could default to the Inquirer Email, rather than the email of the patient. Pam always had to manually copy the inquirer email and paste it into the To line, after first removing the actual Lead from that line. While that was a small initial annoyance, Pam also noted that those outbound messages would disappear as soon as she sent them. Unlike messages usually sent with the email composer, that go into the activity feed, these would send, but not show in the feed on the lead from which Pam just sent them. Being an extremely detail-oriented employee, Pam would copy the text of the email she was about to send and create a Task so that there would be a note on activity feed. Props to Pam for documenting all the communication, but that's a ton of extra work! First, I had to deliver some bad news: I don't think it's possible to have the email composer default the To field to a different field than the standard Email field of the object the composer it sitting on. (Or, if it is possible, it would be enough of a challenge that I already knew that was not where For Pete's Sake would want to spend the effort and cost.) But I was pretty sure I could save Pam from the effort of copying the email contact (before she sent it) and creating a task. Business Problem: User needs to send an email from a Lead record, but not to the standard Email field on that lead, rather to a custom Inquirer Email field. The sent email should be recorded on the lead's activity feed and also on the contact record of the recipient. If the To email does not match an existing contact, create one from the correct fields on the lead (Inquirer First Name, Inquirer Last Name, Inquirer Email, etc.). Relate the message to the contact and to the lead. Figuring Out the Email Composer When you send an email out of Salesforce, you create an EmailMessage. (That's what you link to if you click on it in the Activity Feed.) A little playing with the email composer component showed me a couple of things. By default, when the composer launches on a person record (lead or contact), it actually has that record in the To field, not a text email address. If you type an email address, Salesfore will attempt to replace that with a record (that has that email address). If you use a text email address that is not in Salesforce for any contact (or work hard at using an email that is in Salesforce but don't actually let it get replaced with the record in that field), the message will go to the recipient. (That's good.) But a message that was sent to an email address, not a record, does not show up in the activity feed of any record. (That's bad. More on this below.) First: Down a Blind Alley If you could edit EmailMessages, I figured, maybe I could just put the lead in the Related To field as way to additionally connect that message to the lead. I spent a lot of time trying that. But it didn't work. With a little poking around I noticed that email messages also have EmailMessageRelation records. That looked like it must be a junction between EmailMessage and a contact or lead. Maybe all I needed to do was create an EmailMessageRelation! Nope. I managed to create EmailMessageRelation records, but they didn't cause the message to show in the Activity Feed. Next: Ask the Community Stymied by my first plan, I turned to the amazing Salesforce community. I asked for help in Ohana Slack. JM Hoskinson pointed out that EmailMessages appear to always have a Parent Task that is linked in the ParentId field of the EmailMessage. That seemed like a great place to work from! I think this Parent Task might be what actually shows up in the activity feed. So all I should have to do is find the parent task when an email goes out (under the right conditions) and add the lead into the WhoId field. I spent a very frustrating afternoon to eventually discover that there is no Parent Task if you send to a text email address rather than selecting a Lead or a Contact in the email composer—even if the email address is set as Email on a contact in Salesforce! In practice, this means that if you send to an "email" rather than a "person" (lead or contact) from the Salesforce email composer, your message will go out and there will be an EmailMessage record but there will be virtually no way to find that EmailMessage again in the UI. For starters, it won't be on the activity feed of a contact or lead that has the email address you just sent to. But won't be easy to find anywhere else, either. With hard work I was able to find the outbound messages using the Developer Console, but I already knew exactly the messages I was looking for. How I Solved It Ironically, it's the lack of the Parent Task that I was able to exploit to solve the business requirement. For Pete’s Sake now has a flow called EmailMessage_On Create-Find or create Inquirer and connect. Naming conventions are important. Let's break down how I named this flow: It starts with the name of the object that it's used on. (I intentially wrote "used on" rather than "triggered by." This is a record triggered flow, so EmailMessage is the object that actually triggers it. But even if this was auto-launched or scheduled but primarily works with EmailMessage, I would still start the name with "EmailMessage." That way all flows for the same object sort together in lists.) I don't always include the context—which I know some people strongly recommend. (I think including the context can result in too-long names.) But this flow fires only On Create, so I thought it was worth noting that in the name for speed in understanding. And then after the hyphen I give a short title indicating what the flow actually does. Here's what this looks like on the composer canvas: While that's a lot of nodes on the canvas, the logic and actions of the flow are relatively simple: It's a record triggered flow that fires when an EmailMessage is created and ParentId is blank (meaning "does not have a Parent Task"). Looks for a contact with the email address this message went to. (Most inquirers are going to be new to us, having just inquired about one friend, so they won't be in Salesforce yet. But if there is a contact, creates a task on that contact for this email message.) If there is not a contact, finds a Lead with that email in the Inquirer Email field. (If none is found, the flow ends. That is for the case of an email sent to a text email field that has nothing to do with the case of writing to the Inquirer on a lead.) Then creates a new contact from the Inquirer fields. Then creates two tasks, one on the contact and one on the lead. The Task on the lead has a link to the contact that was created in the body of the Task so that when you view it in the Lead activity feed you can easily navigate to the newly-created contact for the Inquirer. (At the time of this flow firing, the created contact—the Inquirer—is independent of the lead. But when the lead is converted there are flows that will create relationships between the patient and the other people on the lead, including finding the Inquirer that this flow just created as a contact.) Do Try This At Home I hope this inspires you to create cool solutions for your organization's challenges. Have you created a flow to solve an email-related challenge? I'd love to hear about it

I’ve written about and maintain a Crowdsourced Salesforce.org Pricing Guide because it can be hard to figure out what various Salesforce products cost, particularly user licenses. I wish Salesforce.org, in particular, were better about making prices transparent. What You Need: Lightning Enterprise Edition 😍 A “Lightning Enterprise Edition” license is the Salesforce.org branding of a Sales Cloud license. These cost $495/year and give full access to everything in the Nonprofit Success Pack (NPSP), all parts of standard Salesforce Sales Cloud (including Campaigns), and even parts of the platform that are technically part of Service Cloud (the Case object, case routing, etc.) These are the kind of licenses you get free with your P10 donation. What Orgs Often Get: Lightning CRM Edition 😢 “Lightning CRM Edition” is a branding of a Sales Cloud license + a Service Cloud license and it costs $576/year. The Features That’s 16% more expensive, so you probably would like to know what you get for that extra cost. Not much. The addition of the Service Cloud license allows that user to create and edit Knowledge articles. So having at least one of these licenses in your org is the prerequisite to actually publish a knowledge base. (Other users have Read access on Knowledge articles, but nobody could write any.) If you don’t use Salesforce to publish a knowledge base, then the Service Cloud license isn’t doing you any good. (And while a Salesforce Knowledge base may be a good way to write and maintain your documentation, there are free and cheaper options.) We’re Talking NPSP/EDA Today Everything I wrote above has to do with licenses for Nonprofit Success Pack (NPSP) and Education Data Architecture (EDA). The new offerings (Nonprofit Cloud and Education Cloud) have additional permissioning that is granted via an overlay to the base license (a "permission set license"). Those licenses are a separate SKU at $720 per user. I believe there are a lot of nuances to Nonprofit/Education Cloud licensing and I don’t understand it yet. (I’m not even sure Salesforce.org understands it all yet.) Someday I’m sure I’ll have articles about all that. But not today. Why Do Orgs End up with Sales+Service? It is disturbingly common for orgs to be sold their 11th license at $576. And once that first paid license is on the contract, it’s very likely that all future licenses will be of the same type because the org just won’t realize what’s happened. You can only add licenses self-serve through the Your Account app of types that are already on your contract. It really makes me angry when Salesforce sells a small nonprofit a higher priced license than they will ever actually take advantage of. That’s just taking money away from the nonprofit’s mission. I don’t know if it happens because the AE is ignorant or venal, but it seems to happen quite a lot. If it’s ignorance, then Salesforce.org’s sales team needs to do some training. But it sure seems like this happens a lot because it’s AEs selling a higher priced SKU to pad their commission. As I noted, it’s extremely unlikely that orgs need a Sales+Service/Lightning CRM license. The features it unlocks aren’t ones most nonprofits use. And it just wouldn’t be that hard for Salesforce.org to put systems in place to watch for sales of this license type and look into whether it was actually needed. That they’re not doing so means they don’t care. This problem has been called out in the community many times over the years. I’m pretty comfortable being strident about it today. Bottom Line You should pay only $495/year for your 11th and later licenses. If your AE sends you a contract with something higher, give them one quick chance to correct it. If it’s not corrected fast, ask to talk to their manager and give that person an earful. You’ll be doing a service to the nonprofit community.