Search Results

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.

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.

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.

It’s pretty unlikely you need to pay for a full copy sandbox. Not impossible, or maybe it would be better to say, “Not never.” But most of the time it would be an expense you don’t get value from. Don’t get me wrong: I think sandboxes are terrific. (One post already about them. More planned.) You should make it your practice to use them, particularly for building and testing new functionality. Enterprise Edition’s sandbox allocation is 25 developer sandboxes, one developer pro sandbox, and one partial copy sandbox. That’s likely to be more than you will ever need. Access to a full copy sandbox is something that AEs suggest because they’ll make a fat commission on the sale. Even more, they use access to a full copy sandbox to try to sell you Unlimited Edition (which you definitely don’t need). The Cost You can purchase a full copy sandbox a la carte. According to the Salesforce.org pricing sheet, a full copy sandbox costs 30% of the net licensing cost of your org. [Side note: It’s not easy to find that pricing sheet on the Salesforce.org section of the website. Despite years of community clamor for transparency in pricing, I still point you toward the Crowdsourced Salesforce.org Pricing Guide, which I have written about before.] 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 a full copy sandbox is $1,485. It could easily go up from there. (For example, on new Nonprofit Cloud, instead of NPSP, your first ten licenses are each worth $720...) The Features A full copy sandbox is an interesting tool. At the moment you spin up a new full copy sandbox it’s literally a clone of your production environment, metadata, data, and all. It even has the same record Ids for things. And it’s large enough to have everything, even if you have absurd amounts of data. So large organizations need a full copy sandbox when they want to test new development against sufficiently large datasets or even testing new integrations and how they will work with all your data. Plus full copy sandboxes are often helpful in the context of a migration project. Keep in mind, though, that full copy sandboxes can only be refreshed every 30 days. So you have to plan your strategy carefully. These are not as flexible as developer sandboxes. When to Use One Full copy sandboxes have use cases, so I’m not 100% saying you don’t need one. But you only need one if you have plans for it. Examples: A nonprofit that is consolidating two orgs down to one but one is remaining live. Having the full copy sandbox allows you to work on the consolidation project against the full data volume. A two-phased project where you need that full copy to run automation load testing, etc. You complete Phase 1, then spin up the full copy, then all Phase 2 work can be tested against real data volumes. I suppose you could also use a full copy sandbox as a poor substitute for a backup and restore tool. As long as you remember to do it, you could refresh every 30 days and have a monthly backup copy of all your data. The weekly export gives you four times more frequent backup and automatically runs. Plus restoring, if you found a problem, would be quite painful from a partial sandbox similarly to the weekly backup. So I don’t actually recommend this. But I suppose you could use a full copy sandbox this way. Why You Don’t Need One All The Time If you have a project in the works that is going to take advantage of a full copy sandbox, Salesforce’s AEs will be more than happy to sell you one at any time. You’ll be able to add it to your contract mid-year at a pro-rated price. (And then you should ask to have it removed when your contract renewal comes around again!) If your project timing crosses your contract year, you may end up paying for a year and change (because you can’t lower your contract mid-year), but it’s not something you need in perpetuity. Only pay for it when you’re going to use it. [As I said: Unless you’re a really large org.If you have multiple consultants plus a lot of internal folks doing development, maybe you do need a full sandbox. Maybe you’re even of the size that you need UE and, therefore, get one as part of that edition. But that’s just not that many organizations.] Poor Man’s Full Copy If you put a little effort into it, and your org isn’t too large, you can make a partial copy sandbox serve as a very credible stand-in for a full copy. When spun up, partial copy sandboxes also have record Ids that match production. And they can hold 5GB of data, which is quite a lot. So if you build a sandbox template that is broad enough to bring in all your records, you’ll effectively have a full copy. For free! Plus partials can be refreshed every 5 days, so you can iterate on testing more quickly. I think partial sandboxes are pretty handy. I’ve done testing for two household account migrations without ever looking for access to a full copy sandbox. (In fact, I did most of the testing work for both of those using developer sandboxes that I filled with real data using CumulusCI’s data loading powers.) Again, unless you’re a huge org or have a specific project with specific kinds of data or volume needs, you can probably do anything you need in a partial copy sandbox. Bottom Line You only need a full copy sandbox when you have plans to use it. Don’t pay for it when it will sit untouched.

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!

It’s time for a new series on Free Like a Puppy! I’m going to write a few posts about Salesforce products that I seriously doubt you should pay for. Clearly every organization is different, but I’m going to make sure to give specific reasoning. I also got help with this series from a very smart friend in the community who prefers only to be identified as a 🥷🏻. Thank you Ninja Friend! You Don’t Need Unlimited Edition Let me put it in black and white: nonprofits and most higher ed organizations do not need Unlimited Edition. I’ve already referenced this before, but now I’m going to get into the specifics of why I believe you do not need Unlimited Edition (UE). That means YOU. 🫵 There are a small handful of the very largest nonprofits that might benefit from UE. We’re talking about the really big ones: the Red Cross, Goodwill, Habitat for Humanity—orgs with millions of records and crisis moments when thousands of donations can pour in during a short time. If that’s your employer, great! (And I’m thrilled to have you among my readers.) But if you’re working at or with the other 49,990 (or so) nonprofits on Salesforce, I’m pretty confident in asserting that you don’t need Unlimited Edition. Unlimited Edition Includes: - A full copy sandbox - Premier Support - Some AI features - Additional API calls - Ability to create over 200 custom objects (besides those installed by managed packages) - Up to 800 custom fields per object (up from a limit of 500) I’m going to leave aside those first two items here because I will be writing about them on their own. (Spoiler Alert: You probably don’t need either one.) But a full sandbox and Premier Support are the two headline benefits of UE. These are the things AEs push as reasons for the upgrade. I don’t think you need them. I’m going to clearly lay out why not in upcoming posts. The other items in that list probably don’t mean much to you. If you don’t already know what they mean, then you definitely don’t need to pay for them. But in brief: - AI features that nonprofits won’t use. (See here.) - If you are using more API calls than you get in Enterprise Edition you are probably doing something very specific. Look at what that is and think about all the options. See if you can reduce those API calls. - I shudder at the thought of more than 200 custom objects or 800 fields on an object. If your architecture calls for so many objects, surely you are supporting very different functional areas. Perhaps a multi-org strategy would make more sense? Yes, there are costs to that. But if you’re that complex, consider the possibilities carefully. The other “features” of UE are: UE costs $864/user/year (at discounted nonprofit price). [Remember: You can always check the Crowdsourced Pricing Guide if you want to know what you should be paying for any given license. But I'll help you out: What you should pay is $495/user/year.] Yes, you read that right, UE is 1.75X the price! You’re still getting almost an 80% discount from list price. (List price for UE is $3,960.) It’s not quite as bad if you are on New Nonprofit Cloud (NPC). Those NPC licenses are already more expensive ($720/year on EE). Going to UE on NPC is $1,200, so “just” 40% more per user. No free licenses at all. None. Not a typo. If you go with UE, your Power of Us grant no longer includes any free licenses. (You don’t get "the P10.”) You’re paying infinitely more for those first ten licenses! Now it’s more than twice the price. Can’t downgrade. If you select UE, either at initial implementation or if you upgrade later, you will not be able to downgrade to Enterprise Edition (EE). It might be possible to go back to EE so that all your licenses are cheaper. You’ll pay less, even on the the first ten licenses. But you can’t actually downgrade to get the free licenses back. If you want to get back your P10 free licenses, you would have to do an [expensive] org migration. Follow the Money Have I mentioned that AEs push UE? (I think I may have.) I’ve heard multiple reports of them pushing it rather hard, in fact. Now you can probably tell why. They’ll get a lot higher commission if they can sell you on Unlimited Edition. Too bad your organization won’t be getting any benefit. And sorry you’ll be permanently locked into higher prices. I think someone at .Org ought to have an alert watching for a sale of UE and look skeptically at whether the buyer needs it. As I said, they almost certainly don’t. They don’t just "not need it," they actually get negative value from it. An AE that sells UE improperly should be reprimanded. [If you ask, I’ll tell you how I really feel.] Bottom Line You do not need Unlimited Edition. Save your money!

I want to take a moment to step back and marvel at something: We regularly use the phrase "accidental admin" in the Salesforce community. And we use it to refer to people for whom this is now a significant part of their job, if not their whole job. Think about that for a moment. Even if it's not everyone and even though we all know there is quite a lot of diligence and learning required to go from being volun-told that you are going to work with this new system to understanding how to truly be an #AwesomeAdmin, there are plenty of people whose careers took off because they stumbled on Salesforce. They aren't aspiring coders that found Apex instead of Python. They aren't aspiring systems designers that happen to work with Salesforce rather than Microsoft Dynamics. These are usually non-technical people that realized their organization had a need and found that they could make a custom application to meet that need using Salesforce. Do you regularly hear of "accidental auto mechanics" or "accidental mobile app developers"? No, you do not. I believe lots of people could study cars or coding and could learn enough to become mechanics or developers. But people don't "fall into" those things. People do, however, "fall into" Salesforce and then turn that into a career. Lots of people take the tools at their disposal and string together "systems" to accomplish their work. That might mean a Google Form that feeds a shared document along with outbound communication from a common email address, plus who-knows-what-else. They get it done. Nonprofits, in particular, are scrappy and Can Do like that. Small businesses too. But once you've created that process, trained your colleagues how to use it, let it run for a while, and patched the problems that crop up, you still don't have anything coherent to add to your résumé. Thanks to free training like Trailhead, the ability to spin up as many developer orgs/trial orgs/Trailhead Playgrounds as you want, the help and support of the generous Salesforce community, and—most crucially—the fact that Salesforce's back end is pretty easy to work with, it's not just possible but relatively common for the person in charge of that mishmash "system" to upgrade and move it onto Salesforce. You can not only list that on your résumé, you can even get your next job doing it full time. Can we pause to appreciate how marvelous that is? Where Credit Is Due I wish I knew who to thank for this directly. (I suspect the credit goes mainly to Parker Harris.) Someone had a vision for making Salesforce's back end accessible and the overall platform deeply customizable using "clicks not code." Salesforce teams from product managers to coders should share in the glory because they helped turn it into reality and continue to expand that vision. It's amazing! This did not come about by accident—Salesforce was and is designed to be easy to customize without writing code. And because of that, more people can work on the platform. The community would not be nearly as dynamic without the tens of thousands of people that build and configure but do not understand a single line of code. Maybe it's even better because so many non-technical people get involved: they have questions and people help them with answers. I have a certain level of technical aptitude, but I do not code. The closest I came to code was hand-writing HTML for websites back in the 1990s. (And I never enjoyed that.) Still, in 2012 I was able to pick up Salesforce and, with help from the community, make it work the way I needed and my colleagues could understand. I'd tried similar things at previous positions using MS Access and FileMaker without nearly the same kind of success. Leading with Gratitude That's all I wanted to say this week: Thank you, Salesforce, for making this thing that has brought together a community and empowered careers. I may ask challenging questions at True to the Core and I might write about some difficult subjects on this blog. But I also hold it in my heart that this platform, this technology product, is something special.