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.