Search Results
76 items found for ""
- Thing I Learned: Email Encoding Has Changed
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.
- My FlowLog Object
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. ⚙️
- Email to someone not [yet] in Salesforce
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
- Things You Don’t Need: Sales+Service
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.
- Things You [usually] Don’t Need: A Full Sandbox
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.
- Things You Don’t Need: Unlimited Edition
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!
- In Praise of "Clicks not Code"
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.
- Prices Go Up (Discount Goes Down)
News Flash: Salesforce announces 9% price hike. Nonprofit prices rise 14.6%. I've been trying to get confirmation of why there is a higher price increase on nonprofits than for for-profits, with no success yet. Here's my best guess of how it came about: The Public Announcement On July 11th, Salesforce announced that it was going to raise its license prices by 9%. Though it made news, there wasn't a whole lot of discussion or consternation within the Salesforce community. Prices hadn't gone up in years, so maybe it didn't seem that unreasonable? I don't really know why there didn't seem to be more pushback. Maybe in the wake of Salesforce's layoffs earlier in the year a price increase didn't seem nearly as significant... The prior list price for a Sales Cloud license was $1,800 per year. When the price increase went into effect, those licenses rose to $1,980. Note: If you work for a for-profit business: you should not pay list price for licenses either. Ask for a discount! No Mention of Nonprofit Prices At the time of the news announcement, I didn't see any public communication about pricing for nonprofits. Most of us assumed their pricing would go up by the same percentage. We were much more focused on questions like whether the P10 donation would apply to the New Nonprofit Cloud, how much additional Nonprofit Cloud licenses would cost, and the like. Before the price increase, nonprofits purchasing their 11th and future licenses paid $432/year. If you do the math, that comes to exactly a 76% discount for nonprofits paying for licenses after the P10 grant. How Much Is the Nonprofit Discount, Anyway? Math aside, Salesforce has never actually committed to a percentage discount in nonprofit pricing. I have, in fact, argued strongly for years asking for Salesforce to give a clear number for the percent discount that nonprofits can expect on any given Salesforce SKU. I've asked for it in both public discussions and in private conversations because I believe that pricing transparency would be helpful for nonprofits. I've never gotten a clear answer on why Salesforce can't just give us a discount percentage. It seems to be tied up with their difficulty in providing clear and transparent pricing in general. Yes, prices are finally available on the website, but it was quite a struggle to get to that point. Before that was printed, the for-profit list prices were much easier to find than anything about what nonprofits would pay. That is exactly why I felt I had to create and maintain the Crowdsourced Salesforce.org Pricing Sheet. (Now that more is public the sheet may not be necessary, but I still think it's far more convenient than having to hunt around different parts of Salesforce's sprawling website.) Before creating that sheet (and after it went live) I asked repeatedly for a statement to the effect of, "Nonprofits can expect that most Salesforce products will be discounted 76% or more from list prices." I couldn't get Salesforce.org to commit in public to such a rubric and I do not know why they refuse. The clearest reason I ever got was that it risked understating the discounts that were available on some products. But that seems a paltry excuse to me. Nobody is going to complain when some things are even cheaper than that rubric would imply. And it would not be hard to follow up a blanket statement with details indicating that some products might be excluded and others discounted even further. As long as you say "at least X%," you have plenty of room to discount further! I even offered to help edit a statement to ensure it would be clear and unambiguous. Salesforce.org would not budge. My Best Guess: No Guideline Lead to a Higher Percentage Increase I think the lack of a clear statement about the discount is what lead to .Org raising prices more for nonprofits than Salesforce raised them for everyone else. Though it was obvious on the crowdsourced pricing sheet (and from the math) that the discount came to 76% on licenses, it was not officially a "76% discount." Rather, there is no discount percentage, there is just a different price book for Salesforce.org than for Salesforce.com. The prices are not technically tied together. It was coincidence that a Sales Cloud license was 76% lower than list price and a Platform Starter License was also 76% lower than list price. As a matter of policy, there is simply a "regular list price" and a "Salesforce.org price," each published independently. Of course, people don't think that way, particularly when you look around and see that licenses of one type are discounted the same percentage as licenses of another type. You quickly come to a shorthand. I'm speculating here, but I guess that people within Salesforce.org had a shorthand number of 75% in their heads. (I'm pretty focused on the prices but I don't think I would come up with 76% at a moment's notice. I would have said 75% and then tried to remember to check before giving imprecise information.) So when the list price rose by 9% and it was time to publish new prices for Salesforce.org, someone probably took the new list price ($1,980), reduced it by 75% with a quick tap on their calculator app, and then advocated for the new prices, when published, to reflect that math: $495. Oops, That's Much Higher! Here's the problem: The prior price was $432. The new price is $495. $495/$432 = 1.145833333333333 Licenses are 14.6% higher than before! It hasn't hit most organizations yet, but those that pay for licenses will get bills 14.6% higher than last year. 💸 You can already see this if you go into the Your Account app and look at adding an additional license. They're now $41.25/month. They used to be $36/month. Actually, this means that if you add licenses mid year you will already pay the new price, pro-rated for the remaining contract length. You just won't pay the higher price on your existing license count until your renewal date. Sorry to be the bearer of bad news.
- Platform Events — My New Favorite Tool
According to my Trailhead history, I completed the Platform Event Basics module on 12/9/17. So it's more than a little while since I first learned about them. But just in the last month or so I've kinda become obsessed. When I first read that module I barely understood it. And it's no wonder! The intro to the first section suggests understanding object oriented programming (I barely do.) and that "familiarity with the concepts of Streaming API(CometD) and Pub/Sub API is helpful for this module although not required." I have zero familiarity with those concepts. The hands-on challenge requires Apex triggers. I'm no coder. I know enough to be dangerous or to complete a Trailhead challenge, but I would never write code to go into a client org! All that is to say that the concept of platform events might seem a little intimidating to you. That's OK. It was intimidating to me as well. But I have realized that they can actually be pretty simple and incredibly useful. That's why I want to share with you! The Concepts Needed to Ferment Like I said, it's almost five years since I first learned about platform events from a Trailhead badge. At almost no time in the interim did I consider that I might have a use case for them. They sounded very developer-y. But the knowledge was tucked away, apparently. In January 2021 I completed Application Integration Patterns for Salesforce Lightning Platform. (There's an exciting sounding badge, right? I think I must have been bored. Or working toward some arbitrary number of new badges.) That was yet another badge that didn't seem to have a lot of relevance for me. And it was almost two years ago. But apparently concepts from that badge started rattling around my brain, eventually sticking themselves to platform events, which were also bouncing around in there. Pub/Sub (short for Publish/Subscribe) If you don't want to read that whole application integration patterns module (And why would you?), I think of pub/sub as breaking apart the act of writing something from the need for anyone to read it. Like writing a blog, sending out a tweet, or even posting on Facebook, the "publish" side of the action is something done only by the writer. Or maybe it's more like a town crier, shouting their message that "It's ten o'clock and all's well!" Or the muezzin chanting the dawn call to prayer from the top of the minaret, "It is better to pray than to sleep." Somewhere, the writer or the crier hopes, there is someone "subscribing" to their message. I sincerely hope, when I write one of these posts, that you subscribe and read. The muezzin sings not for his own benefit but to draw people to the mosque. Theoretically we could all just be shouting into the void. I guess one difference from my metaphor is that a pub/sub integration pattern has, by definition, some means of subscribing. That's what makes it an integration pattern. Fire and Forget This is the one that really didn't make a lot of sense to me at first. The "forget" part kinda' freaks me out! Do I want to work with any kind of integration that just sends off a message without knowing that it was received? It's like sending an SMS without even the notification that it was "delivered." Even when you get that—or even better, a "read" receipt—do you really believe the text was read before you hear back from your friend? I suppose any uni-directional integration is kinda' fire-and-forget, since the sending system doesn't necessarily get back data from the receiver. But I've mostly worked with middleware such as Zapier. The sending system might not get data back, but Zapier at least knows it has successfully taken action on the receiving side. So Zapier could report an error if needed. I'm not certain I can explain the difference between the two concepts, now that I think about it. "Pub" and "fire" seem basically the same to me. "Sub" can't be a whole lot different than making sure your "fire" is aimed somewhere that's ready to receive, can it? Maybe someone smarter about these things can help me out? Are Subscriptions Reliable? Can you fail to notice a platform event? Despite my lack of understanding, those combined concepts must have fermented in my subconscious. I think I had a vague notion that something called a "platform event" could be "published" (or "fired") and that a "platform event fired flow" could "subscribe" to listen for it. But I didn't know if I was missing some important context or nuance. And I really didn't know if it was reliable. Could the subscriber ever miss a delivery? I subscribe to the daily hard-copy newspaper, but there are plenty of days when delivery is late, never arrives, or the paper is wet and unreadable. Even e-newsletter subscriptions sometimes get diverted into my spam folder. And just because I "subscribe," that says nothing about whether I read the paper, let alone any given section or article. These were the questions that I've had about platform events for several years now. And platform events don't seem to get mentioned very often in blogs or presentations, so I didn't really learn anything more. Then at the end of August I stayed in the Amherst, MA, home of Salesforce MVP and brilliant system architect Chris Pifer, who I've worked with many times at Open Source Sprints. We were nerding out late into the night over Salesforce stuff. (As one does.) At some point Chris mentioned that he had been using platform events recently to allow for an interconnected and extensible set of automations in a large enterprise implementation. (At least, I think that's what he described. Honestly, he was way over my head.) That lead me to ask Chris some of my questions about platform events, including the big one that worried me: Could the subscriber miss the publication? Chris assured me it could not. I don't remember if this is how he explained it or not, but what I eventually took away was that the pub/sub of a platform event is similarly reliable to the create/update of a record and the "noticing" of that event by a record triggered flow. My gears started turning... Potential Use Cases Come Calling Mass Invoice Insert Over the summer I had a client with a need to create a whole bunch of invoice records each month. I created a screen flow that has a pause before calling a subflow, so the large amount of records that need inserting happens as part of a separate transaction. (In fact, there's another record-triggered flow that creates child records of those records, also after a pause.) I was concerned that even with the pauses my flow might still fail. What if the screen flow designated more records to be created than the subflow could handle without hitting limits? I tested as best I could in a sandbox and then crossed my fingers when I got to production. It works, but I still have a nagging suspicion that it could be brittle. (It's on my list to refactor, but for now we go with, "It ain't broke. Don't fix it.") Frequent Recalculation of Child Records Then in September I started work on a tangle of flows for another client, The Modern Classrooms Project. That task turned up an interesting dilemma: One of the flows we needed would fire upon delete of an opportunity product, calling a related flow that would determine needed revenue recognition child records for the opportunity. (Let's abbreviate "revenue recognition" to just "revrec.") But flows can only fire in a Before Delete context. That meant that our flow picked up the deletion of the opportunity product and called the opportunity flow to recalculate revrec records. But that recalculation ran before the product was deleted, which is functionally the same as not running at all in this case. I reached out to the community looking for suggestions to force my flow into an After Delete context. In the course of that discussion I wondered, after my conversation with Chris, whether we could have the before delete flow publish a platform event, then fire a platform event fired flow that would be in an after delete context? Consensus was that it might, but the only way to be sure would be testing. (The easiest option the community suggested was to pass the Id of the deleted record to the revenue recognition flow to be excluded in the Get Records for products. I went with the easier—and guaranteed—option.) But there was enough suggestion that it might work to make me want to revisit the question later. The Moment Arrives That same Modern Classrooms tangle of flows threw us another curveball that finally gave me the excuse to try out platform events. We realized that we need to force recalculation of revrecs for opportunities if they cover the period in which a new session is going to happen, or if a session's dates change to move it into or out of the period of a contract. Modern Classrooms is growing fast. I could envision a time not too long from now when there could be dozens or even hundreds of opportunities impacted when a session changes. I thought I could probably use the paused flow trick to process those changes asynchronously. But the idea of trying out platform events to process those changes closer to realtime seemed worth a bit of playtime. And it worked! It was actually surprisingly easy. Payload Delivered Platform events are like Salesforce custom objects, in that they can have fields with data in them. But platform events do not persist in the database as records. (And they can't be viewed in the user interface at all.) Platform events are metatdata and get configured, similar to a custom metadata type (CMDT). But unlike a CMDT, you can fire a flow when a new platform event is published. (I wanted to write "call a flow from a platform event record," but I think saying "record" would be confusing because that platform event "record" only exists long enough to be heard by a subscriber, there is no "record" sitting in the database for later viewing.) To expand my metaphors from earlier, a platform event isn't just published, it isn't just shouted into the sky—it can carry a payload of meaning. The town crier doesn't just make noise at 10pm, he can deliver a message that "All's well!" or "A storm's a-comin'!" Maybe it's the difference between a public clock that can chime only the hour and a PA system that can make a sound on the hour or give a news bulletin. Or it's the difference between birdsong that is "just sound" to us, but has meaning for the other members of the species. Or the hideous noise of a fax machine or modem that actually sends information from one device to another. Or the random-looking pattern of squares on a QR code that your camera can interpret as a web address. Or, you know, squiggles on a screen that you and I interpret as "writing." [Enough metaphors for you yet? I could probably come up with more.] So the heart of my first platform event-based solution was simple: I made a platform event that would carry a very small payload: the Id of a single opportunity, one whose revrecs need recalculation. When a session is created or updated, I have a flow that finds all the opportunities that are impacted and defines platform events for all of them. Then it publishes all those platform events, one for each opportunity. One platform event is shouted into the world for each opportunity that needs revrecs recalculated. Meanwhile a platform event triggered flow is subscribed to The Opportunity Network. Each opportunity Id, as it's shouted, triggers a very simple flow that finds the opportunity and checks a box on it called "Recalculate RevRecs." Can't get a lot simpler than that, right? There's one more flow in our solution. It's a record triggered flow on Opportunity. If Recalculate RevRecs is checked, it calls the revenue recognition flow and then it unchecks the box (to ready it for use in the future.) Depending on your Flow skills, this might either sound very simple or a little complicated. But I think you can follow that each individual flow is pretty understandable. So stick with me. One to Many to One The cool part is that with platform events we've now taken a single user action (create or edit of a session) and broken its consequence (need to update dozens or hundreds of opportunities) into individual pieces. In normal flow land—whether we do this in one big flow or break the work into a triggering flow and one or more subflows—a single transaction (the create or edit of one session) is going to result in a cascade of record updates (changes to the revrecs for many opportunities). Depending on the complexity of that cascade and how many records it happens for, that could be a whole lot of processing going on. And in normal flow land, all of that processing will happen within a single "transaction" that initiated the flow, so all of the processing together has to stay within the Salesforce governor limits. But instead of normal flow land, we process each opportunity individually because they're each kicked off by an individual platform event. This isn't a collection of "opportunities that need reprocessing" anymore. No worries about CPU timeouts, or flow element limits, or a slow page reload after Save. The session is created or updated and a very efficient flow in the background publishes some platform events. Easy peasy. Then one opportunity, then another, then another, in series or in parallel, it doesn't really matter, all do their revrec recalculation. The user experience is fast because the session save and publishing of events is all that happens in the user's transaction. Everything else is in the background. Get Around Specific Limits WIthin a week of finding using platform events for that cool case, we found another way to use them at Modern Classrooms. This time we're going to evade a very specific limit: You can't send more than 10 emails in a single transaction. Obviously you can send email templates and the like but most of the time you're sending a single one in a transaction. ("When an opportunity is moved to Closed Won, email the donor an acknowledgement." That's one email.) But if you want to call the sendemail() method (or, in a flow, use the Send Email action) you can't do it more than ten times in one transaction. This one's tripped me up before! But this is exactly what my colleague Terri wanted to do. She was building a screen flow to allow you to select multiple records in a list view and then send out a list email to the contacts that go with those records, similar to the native List Email function on campaigns. I mean, why should campaign members have all the fun? Terri's a fast learner and not afraid to try things out. So she built a little screen flow and dropped it onto a list view and tested it a couple of times in a sandbox. But when she mentioned it in a meeting, I asked if she had attempted it with 15 or 20 records. She had not. (There are never enough records in a sandbox!) I was pretty confident it was going to hit that send limit. Worse yet, the Send Email action has a limit of five email recipients among the three places you can add them. But I immediately wondered if platform events—my new favorite toy!—could come to the rescue. Turns out that they can! All we had to do was define a platform event with more payload: Recipient Subject Body Sender Set up the screen flow to publish a bunch of platform events, one per selection on the list view. Then a waiting platform event triggered flow (below) takes those fields and puts them into the right places on a Send Email action. Since that platform event triggered flow is working on just a single email, there's no problem with limits. In fact, that flow can even take the step to look up the contact who's the recipient (we originally sent from related records) and could look up records related to that contact... The freedom of working from an entirely separate transaction opens up lots of possibilities.
- Unlimited Edition Means No P10!
(an update to AEs are Salespeople) In my most recent post I noted that AE's are Salespeople and called out some of the ethical lapses I've seen. In response to that post one of my close friends, who is a senior consultant at a medium sized Salesforce partner reached out to ask if I could update my post to add a bit of information: Upgrading to Unlimited Edition means that you lose the P10 donated licenses. That is a very big deal! Let me restate it: If your organization chooses to either upgrade an existing Enterprise Edition or starts your new implementation on Unlimited Edition, you will not get any licenses free. Under the Power of Us Program all nonprofits get ten donated licenses, known as the "P10." These are licenses for an Enterprise Edition org (or "EE"). Unlimited Edition ("UE") is the next tier up, coming with more data storage and some other potential benefits. (That you don't need. Watch for a future post on this topic!) UE licenses, of course, cost more. They are $864/year, exactly twice the price of EE. So naturally AEs would be incentivized to sell Unlimited! But the P10 grant does not apply to UE licenses. So whereas the first ten EE licenses are free and then the 11th (if you ever grow that large) costs $432, on UE you pay $864 for every license, even your first. Thus the AE that talks a small nonprofit into UE has just garnered themself commission, even for a nonprofit that should pay zero dollars. This is a problem on so many levels. Plus. my friend told me that they have seen "increasingly sleazy" tactics from AEs pushing Unlimited Edition. I've heard that from other people as well, I just hadn't put together the cost difference. Just think about the math for an org with 20 users, which is not that many employees: 20 users on Enterprise Edition = 10 free+10 paid licenses = $4,320/year = 💰 20 users on Unlimited Edition = 20 paid licenses = $17,280/year = 💰💰💰💰 A lot of nonprofits won't realize that until it's too late that they have now signed a contract that gets rid of their donated licenses. It's Hard to Speak Out The person that came to me with this information asked me not to include their name. They told me that they've already had "an AE get cranky" when they pointed out that a particular thing the AE was trying to add to a contract was not worthwhile. This is someone that often is very forthright with their opinions, including in public forums. But they felt that pointing out this sales tactic problem could hurt them and their coworkers. Not The Last Word On This I've made an edit to yesterday's post to mention this particular information. I started this blog in order to give nonprofits the straight information on pricing and value. You'll definitely be hearing more about Unlimited Edition, AE sales tactics, and the like.
- Spoiler Alert: AEs are Salespeople
[NOTE: This post has been edited from it's original publication to include some additional information.] I don't think this should surprise anyone: The account executive ("AE") from Salesforce who reaches out to you when you create a new trial instance or when your organization applies for the free [like a puppy] licenses or when your contract renewal arrives is paid to sell things. They may (emphasis on may) have expertise with nonprofits or education and be able to also serve as something of an advisor. But their job—the only job they get paid for—is to sell things. Never forget that. It's not just the AE. That solution engineer who gave all kinds of interesting suggestions for how you might build your system? She's not actually going to build it for you. She's whetting your appetite so that you'll have a more ambitious implementation. The person who showed you a beautiful demo of the student portal that another university uses is not going to replicate that build for you. They're showing you what you could do if you added Experience Cloud to your contract. I'm not writing to complain that this is a problem. (Well, OK, maybe a little... 😉) Let's Be Realistic We live in a capitalist system. Salesforce, as I have said before, is a capitalist enterprise, a business. Not just a business, ticker symbol CRM is a publicly traded company. Even if Marc Benioff wanted to turn Salesforce into some kind of social enterprise or a charity, he could not. The other shareholders expect profits and growth. (Full disclosure: I am one of those shareholders. A very small one.) I don't particularly love capitalism, much less the late-stage American-style capitalism that has produced so much misery and inequality. But this is the system we find ourselves in, the game we are forced to play. And no matter my feelings about it or yours, Marc Benioff actually seems to be quite fond of capitalism. Given that, I take it for granted that executives throughout Salesforce are also on board with capitalism, even if they work in the nonprofit-serving arm of the company. The Incentives Are Wrong Back to those AEs. Even AEs working for "Salesforce.org" are incentivized directly by profit motive. (I used those quotes around Salesforce.org because I want to remind you that there is only a single entity at this point. Salesforce.org is a division of Salesforce, not a separate organization. The name implies more separation than it should at this point.) As a matter of fact, as far as I understand it, AE commissions are only based on new product sold. That means that when your org comes up for contract renewal, your AE makes no additional money when you simply renew your contract as a happy customer (even if you are continuing to pay for licenses beyond the 10 free ones). They only make money if you buy new licenses or add new products. Stop and consider that for a moment. Your AE does not make money if you are simply a happy customer continuing to use Salesforce for another year. Your AE may be glad to hear that the system is making you more efficient and effective at your mission. They may be thrilled that you work with a wonderful consultant who has built you custom functionality that you love and that by supporting that consultant you grow the Salesforce economy. They may appreciate that you have hired your first full-time Salesforce admin and, therefore, have grown the workforce. Your AE might even enjoy hearing that you have purchased products from AppExchange partners, growing the Salesforce ecosystem. But when it comes to whether or not your AE has met their job goals, none of that matters. Their commission and their job performance is only evaluated based on whether you buy more licenses or add new Salesforce SKUs to your contract. If your spend doesn't rise, neither does their bank account. Personally, I think that's a poor incentive structure. I realize that this is nothing more than my opinion—and that I have never worked in a sales environment, much less managed workers in one. But I think there should be room for AEs within Salesforce.org to earn recognition (including commission) for helping organizations that use Salesforce to thrive and to continue their use of the system. No Illusions Even if the incentives didn't deprioritize steady-state usage, I recognize that Salesforce and AEs would be more interested in the bigger nonprofits. Of course it's going to be better for the company to sell 100 full licenses and 500 community licenses to a larger nonprofit than to deal with a small organization that only uses the P10 grant or may someday purchase a single license. Of course it's going to make sense for the company to get in the door of a higher education institution than to spend time working to get or keep a tiny nonprofit customer. There's probably no way within a capitalist structure that this wouldn't be the case. I'm resigned to the fact that there are structural reasons why Salesforce.org is going to focus on larger nonprofits and higher ed. That will skew how AEs do their job, how products are designed and built, and what voices are heard by executives within the division. I recognize this reality. But those deals should still be structured ethically. AEs should not profit from selling unneeded products and services to nonprofits, draining scarce resources from their mission. Unfortunately, they do profit from this. Not a Rare Problem I regularly hear from consulting partners about deals where an organization was convinced to purchase all their licenses up front (even for an implementation that might take a year to build), or sold licenses for a Community ("Experience Cloud") that they would never need, or convinced to add a high-priced SKU to the deal, or sold Unlimited Edition licenses when their data volume would never justify the cost. I hear these stories too often for them to be rare—I'm just not that well plugged in to Salesforce partner gossip. If I hear about it as often as I do, it means the misplaced incentives are encouraging this to happen somewhat regularly. Here is another major problem: Salesforce.org AEs are pushing Unlimited Edition ("UE") and talking up the Power of Us donated licenses (the "P10"). But if you go with UE, you do not get any free licenses. The P10 grant is only for Enterprise Edition. For more discussion of this, see this update. Those are the egregious examples. But I also hear about small wastes of nonprofit money, like selling the 11th and future licenses after the P10 grant as "Lightning CRM Edition" (Sales + Service Cloud) for $576/year even though basically all nonprofits use "Lightning Enterprise Edition" ($432/year). Just a couple of weeks ago someone I know discovered that her client was paying $576 for all of their licenses, for absolutely no reason. Once in a very long while there could be an organization that needs an extra Sales+Service license, but it's a vanishingly rare occurrence. Someone in management for the Salesforce.org sales team should notice when one of those is sold and ask, "Are you sure?" Not watching for that is simply taking money away from the mission of nonprofits because nobody at Salesforce.org cared to correct the mistaken overcharge. Where are the Partners in this? Unfortunately, the problem isn't just with Salesforce's sales team, it bleeds into partners as well. I am not accusing the partners of actual wrongdoing, but let's "follow the money," as they say. If you are a consultancy that gets referrals from Salesforce (which is supposed to be the point of the partner program and is the lifeblood for larger consulting partners), then naturally you don't want to antagonize the company. If Salesforce sends you a deal that involves overcharges like excess licenses or SKUs, you're going to be put in a tough spot. By the time the partner gets that referred business the Salesforce contract has already been signed. Even if the partner wanted to counsel the client against the oversell, it's too late. And I can imagine it would be pretty awkward to start your new client relationship by telling them they've wasted money. I know there are partners that have that difficult conversation with their new client. Sometimes they do it quietly, arming the client for dealing with Salesforce when renewal rolls around, or trying to help them claw back part of the deal. I think they most often do this secretively, telling the client what they need to know, but trying to cover their tracks so that Salesforce won't punish them with fewer deals. But I also suspect there are some partners that either turn a blind eye or even participate in unnecessary upcharges if they get a cut of the deal. In fact, I edited the original publication of this post to include the paragraph in the previous section about Unlimited Edition not getting free licenses. (And this paragraph, obviously.) I added that because a friend that works for a medium-sized consultancy specifically asked if I could highlight that information. When I asked if I could identify them as my source, they asked that I publish this without their name. They were concerned for themself and their coworkers because an AE has already been upset with them for advising clients not to buy a product they don't really need. Full Disclosure I am a Salesforce Partner, at least on paper. A couple of years ago they made it free to register as a consulting partner. Since it was free and came with some potential benefits, I figured it couldn't hurt to sign up. Unfortunately, something about my login never worked. After several back-and-forths with Support, I gave up. Then, about a year ago, when the kerfuffle about new Nonprofit Cloud was breaking out, it became clear that there were conversations in the Partner Community that I might benefit from being a part of, particularly if I wanted to understand and interpret for my readers on this blog. And there are learning resources for partners that I couldn't access even as an MVP. So I put in the work with Support and finally become "officially" a partner. As a matter of fact, at the time of this writing, I actually can't log into the partner portal once again. No idea why. I've filed another support case. So much for accessing those partner benefits. I'm getting notifications for posts in the partner community but I can't even access the rest of the thread. Bottom line: I am a Salesforce Partner in name only. I have never gotten a deal referral from Salesforce and I do not register deals when I bring in a new client that is going to implement Salesforce. This is intentional. I want to maintain full independence to advocate for what I think is right for my clients, for nonprofits, and for the Salesforce community. I want to be able to say whatever I want on this blog without fear that someone could retaliate against me and hit me directly in the wallet. Last full disclosure: I'm a member of the Salesforce community. I enjoy opportunities to speak at community organized and official events. I get tons of Salesforce swag, from stickers to sweatshirts. And I'm proud to be recognized as a Salesforce MVP Hall of Fame member, with all the official benefits and swag that entails. These things certainly make a dent in my thinking about the company and probably temper what I write here. So you can take what I say with that in mind. (But I believe it's a far cry from relying on Salesforce to actually support my book of business.) Caveat Emptor (Buyer Beware) So take what I say with full knowledge of my situation. But more importantly, keep in mind when someone has a financial incentive undergirding what they are telling you. And that goes doubly when you're talking with an AE who is literally trying to sell you something. All I can do is remind every Salesforce admin to scrutinize your contract. Check the price guides, including the crowdsourced one that I maintain. Know what a product is before you agree to purchase it. And take a very skeptical look at anything new being suggested.
- No Dreamforce Wrap-up From Me
If you've been reading my blog for a while, you might have noticed that I didn't publish a post-TDX wrap up, nor anything in particular about Midwest Dreamin. And I'm not going to write a Dreamforce '23 wrap up either. Why? It's Been Done For starters, there's more than enough other content already out there on LinkedIn, the social media site formerly known as Twitter, the Trailblazer Community, Ohana Slack, and probably more. With the activity of some social posters you can practically experience Dreamforce in realtime, if you want to. By the time I would write something up it's practically stale! And I am happy to encourage you to read some of the other excellent Salesforce blogs out there, many (or most) of which did have a wrap up. So I don't think you really need one from me. Mostly Marketing Also—spoiler alert!—the content at Dreamforce is mostly marketing. [I hope this isn't coming as a great shock to you. If it is: You're welcome.] I actually don't mean that as any sort of complaint. Really. Salesforce spends millions of dollars on Dreamforce and the purpose of the conference, from their perspective (as I interpret it) is to sell product. It's a fun conference, incredibly well produced (think Disney level of attention to visual detail, but for a tech conference), with free access to a concert from a headline band (this year: Foo Fighters, my first time: U2), and interesting to experience. But the keynotes and the Salesforce-generated content are a chance for the company to make announcements about shiny new things and to generate interest and hype that will get good press and eventually result in profits. No more, no less. The nonprofit keynote had a surprise visit from Sprinty the T-Rex, and that was pretty cool. But it's hardly groundbreaking new announcements of features or products. And the actual "announcements" in the nonprofit keynote (to the extent that I paid attention) were all "AI blah blah" and "GPT blah blah." Nothing that we're going to be using for a while. (I'll write about that stuff when it seems actually relevant.) Before COVID, when Dreamforce attendance topped 150,000 (not a typo!), there were thousands of sessions presented by community members (like me), so there was a massive amount of learning and technical content available. In the post-COVID incarnation of Dreamforce attendance is lower and the number of presentations from outside Salesforce has also been reduced. It's hard to say if it's a proportional reduction, honestly. But if you're really looking for technical learning, you can get it at dozens of Dreamin events for less cost, so I would argue that Dreamforce is just a different thing. That's not to say you can't learn a lot of technical content at Dreamforce. You definitely can. You just have to learn to read between the lines of the session titles and abstracts. Tons of Networking So if Dreamforce isn't for the technical content, why did I spend the money on airfare and hotels? I actually didn't think I was going to bother until the Trailblazer Community Team decided to have a Salesforce MVP Hall of Fame induction ceremony and an all-day conference for MVPs. How could I pass that up? For me the event is about the networking. I saw and met tons of people. As an introvert, it's an amazing opportunity to sit down and go deep so that we really bond. (It's also incredibly overwhelming as an introvert, but that's a topic for a whole blog post sometime.) But it doesn't feel like a Dreamforce wrap-up about all the networking I did would be that interesting... If you weren't there, do you care? Which brings me to my main feeling about Dreamforce recap blog posts: Do people care? If you were there, you don't really need the post. And if you weren't there, am I just lording over you that I was? FOMO Much? If you read this post and all the other Dreamforce content and wondered whether you were missing out, I'll leave you with this bit of advice: Dreamforce is something to experience at least once. It doesn't have to be next year and it doesn't necessarily have to be a regular thing. In fact, I wouldn't even put it first on your list: TrailblazerDX (or TDX) has a lot more opportunities for technical learning and is focused on developers and admins. And it's also run by Salesforce, so you get a lot of the Dreamforce magic, but with fewer crowds. Dreamin events are far cheaper and easier to get to. Content is much more focused on admins and job seekers. You could probably attend three Dreamins for the same cost as going to Dreamforce. Local User Group Meetings - These are, by definition, local and they're also free. Go meet other professionals in your area! If you're involved in the ecosystem I would recommend you try out Dreamforce sometime just to say you have. But see if you can get an employer to pay for the airfare and hotels.