Search Results

I discovered recently that you can put an emoji in an Auto Number field! If you're working on that new custom object and you want its auto-named records to stand out, an emoji as the identifier is more fun than CustObj-1, CustObj-2... [Perhaps this is finally my chance to use that pirate flag 🏴‍☠️, if only I can figure out what custom object it should go with.] Since emoji are nothing but text characters, I don't think I even need to give you instructions. You just add the emoji of your choice into the setup page of your custom object: Now your new records all have a fun and colorful separator! Why would I do this? Because it's fun and colorful! If you need more convincing than that, this isn't for you. What are the risks? I can see two reasons I'm not likely to actually use this any time soon. Risk of Unintended Consequences To be honest, I don't know if there could be unintended negative consequences to using emoji in a Name field. I can think of possibilities, though: Storage: I know that emoji often take extra storage compared to a single character. But at the same time, I know this is also true of letters with diacritics, such as ñ, é, and the like so I'm not super worried here. But it seems within the realm of possibility that the extra storage could result in an error at some obscure point. Output Confusion: Depending on where that Name field is going to be used, the emoji might not be handled gracefully. I've seen copy/paste into some applications fail to paste the emoji. Similarly, a report export might not work right. You'll want to test and keep an eye out. Challenge in Referring to Records This is really the one that's giving me pause. I frequently find myself having to either verbally or in writing reference one or more records of an auto-numbered object. It's annoying enough to type an email about, for examples, Respite-001367 and Respite-001380. If I want to be accurate (and consistent) I have to: Remember if there are spaces around the hyphens or not. Keep the leading zeros in mind, either typing/speaking or omitting them consistently. That's already some level of cognitive burden. But at least I can type those names without lifting my hands from the keyboard or moving my eyes from the screen. But if I had to include emoji in the names, it could be a lot of clicks. And some emoji aren't necessarily that convenient to add when you're speaking the record name either. Just Because You Can, Doesn't Mean You Should If you have a use case where this will give your colleagues a smile and the risks are low, go for it! We should all have more joy in our lives. I'm not recommending this for every object or every org. I do, however, hope I start to see it in demos and presentations!

I love the NPSP Household Account data model. I think it's easy to understand, pretty convenient to work with, and has stood the test of time. It takes maybe two minutes for even brand new Salesforce users to grasp that In Salesforce, all contacts must be on an account (for historical technical reasons that I usually briefly explain). In order to use Salesforce in the nonprofit context (to understand whose money a donation came from), we have the Household Account model. In this model we put all contacts directly on their Household Account. NPSP's triggers handle creating these accounts when you leave the Account field blank. We also have organization accounts (one record type or many) to which we affiliate contacts. Make It Required To keep data clean, I want to ensure that all my records stick with the household account model. So I like to have a validation rule. (You can remind people not to put contacts directly on accounts, but they sometimes forget.) The formula for that validation is quite simple: Account.RecordType.DeveloperName <> "HH_Account" [Remember that validation rule formulas are "backwards." The rule will fire if the formula returns "true," so you want the rule to show what you don't want to be the case.] And I try to have a friendly message, along the lines of Contacts should always be on a household account. (Leave blank and the NPSP triggers will create the account.) Their employer (if you want to record it) goes in the Primary Affiliation field. Mixed Data Models Of course, some organizations intentionally use a mixed data model in their NPSP org. Donors, board members, and anyone else we're dealing with as a "whole person" belong in the household account model. But for program participants we have no need for a household. They can just follow the standard Sales Cloud data model and be directly child to an organization account. For example, a program that runs SAT prep classes in schools can put students directly "on" the account of their school. If we have no need for household accounts for each of the students, it simplifies things. If you're mixing data models, you can still have validation rules. One for the students (or clients or whatever you might call them): And one for the other contacts: Keep that data nice and clean! Lead Conversion Those validation rules can throw a wrench into the gears if you use (and convert) Leads. Even when you enable the NPSP lead convert override (a required post-install step) you'll get an error with validation rules like that. As best I can tell, the NPSP override must initially create the new contact directly on an organization account (or with Account blank), so you hit the validation before the conversion finishes. But four easy steps will fix this: Create a formula field on Lead that returns the Id. Create a text field on Contact called ConvertedLeadId__c. (Leave it off page layouts.) Set your Lead conversion field mapping (Object Manager>Lead>Fields & Relationships>Map Lead Fields) to put your new lead field into your new contact field. Add to your validation rule formula so that if ConvertedLeadId__c has a value, it won't fire. Now when your lead is converted the resulting contact has the Id of the lead it came from in the ConvertedLeadId field, which can be helpful at times. But most importantly your lead conversion won't hit the validation rule!

Good news! Salesforce has listened to the outcry from the community and realized that the terrible user experience I described in my last post would be disastrous. They've already rolled out some fixes that make things better and they're (at least reportedly) working on more. Timeline It would be a fool's errand for me to try to detail when particular changes are coming to your sandboxes or to production. The dates and content for security changes around phishing resistant multi factor authentication and those around step-up reporting have already changed several times, including a full delay in implementation at least once. So I can't keep up with any date changes that could be announced between when I write this, when it's published, and when you read it. As of the moment I'm typing this, the schedule for step-up authentication in production instances is "Starting July 1, 2026, staggered over approximately 30 days." It's that start date that's changed at least once already and could change again. I believe this Help document will stay updated with any new information. What's Already Changed Salesforce deployed a fix so that the truly terrible experience I detailed in my last post, where embedded dashboards on a home page showed an error, is no longer the case. Yay for that! The Help document was updated on June 2 to reflect that change. As of my writing this post, I haven't seen it yet (because rollout starts on 6/15), but another patch is also being deployed in which step-up will trigger when exporting or printing reports, but not when the Reports tab is accessed nor when a report is simply viewed. I assume this will similarly apply to dashboards, but I haven't seen documentation about this patch yet. Quick Tip: Know Your Patch Version If you're logging into your sandbox to test these changes, you may wonder whether you've got the latest update with the fixes you're watching for. Did you know that there's a faster way than going to trust.salesforce.com? Just append /releaseVersion.jsp to your org domain and you'll know your release and patch version instantly! Reminder here about Sprinty's Community Resources. You don't have to keep all these tips in your head. What Might Still Change I'm told the team is "looking at" the insanity of the step-up ping moments after the original login. No confirmation yet that it will be better before enforcement. But they understand the community's frustration around this. I have hope.

Salesforce is about to make their own flagship product (the Salesforce platform) practically unusable. No joke. The added security of the Step-Up Authorization to view reports and dashboards is going to be enforced on or about July 1 (it’s actually staggered over 30 days). Though it’s not enforced in Sandboxes until June 17, you can test how it’s going to work already if you’ve got a sandbox on Summer ‘26. Bottom line: It’s bad. It's gonna break reports and dashboards. And I've written before that reports and dashboards are kinda Salesforce's superpower, a main selling point for the platform over other CRM or online database options. To the best of my knowledge, this post is accurate as of 7:15pm Eastern on June 2nd. It's possible that by the time it's published or by the time you read it that a patch will have changed some of the behaviors I'm writing about. 🤷🏻A few minutes ago Salesforce announced a delay of the enforcement schedule. They've also said that a patch is coming "this week" to sandboxes to fix some things. But we have no idea what things nor how they’ll be fixed. In the spirit of Safe Harbor statements, I can only write about what exists, not what might or might not be better when a patch rolls out. Frankly, given how poorly the initial release works, I don’t have a lot of confidence that their rushed patch is going to get it right. What is coming? “Enforced,” in the parlance of a Salesforce security setting, means that something that right now is an option you can enable or disable is going to be enabled and no longer possible to disable. On a date that’s unclear for any particular org, but is set to be no later than July 31, Salesforce is going to enforce step-up authentication for viewing any report or dashboard. This means two things: First, the “ping.” The user will have to complete a multi factor authentication action. If you’ve been using MFA for a while, this is the same as you’re used to: a notification from the Salesforce Authenticator app that you have to tap to approve. Then "the window." Step-up authentication will last for a maximum time window for what counts as a single authenticated step up “session.” When the session expires, users will have to get another ping before viewing reports or dashboards. The default setting for this window will be two hours (120 minutes) and while it can be set shorter, that is the maximum. On its face, these are both reasonable security measures. (The second one, in fact, I’m fine with. I might wish the window could be longer, but I won’t quibble…) The problem is that the ping is not being implemented in ways that I would consider reasonable or even, frankly, workable. Additional clarifications: First, people originally understood this to be a step-up requirement for exporting reports or taking other such unusual activities. But that is incorrect; this applies to any interaction with reports or dashboards, including viewing even a single embedded report chart. The rollout timing is confusing, especially now that it's been pushed. The original schedule sounded like it lined up with the rollout of Summer '26. But since Salesforce only ever said a date and "on a rolling basis," rather than saying "with installation of the Summer release," it seems like that difference probably means something. The Ping is the Thing It’s dependent on their method of login, but the vast majority of users complete an MFA challenge during the moment of login. Here’s where it gets stupid: That original login MFA ping does not start a “session” that counts toward viewing reports and dashboards. Think about that for a second: I have just logged in. I click to view my daily metrics dashboard. It’s been maybe two seconds (or less) since I completed the MFA challenge. But now I’m getting another MFA ping for the “step-up.” I probably haven’t even gotten my phone back into my pocket! At best, it’s going to feel annoying to have to do two pings just a few seconds apart. But I submit that the vast majority of users are going to contact their admins to say something along the lines of “something is wrong with the Salesforce Authenticator app—it keeps forgetting that I’ve just logged in.” Sure, we can tell them that this is expected behavior. But it’s dumb expected behavior. If that were the extent of the problem, I would not be writing this blog post. I’m making a big deal because it gets a whole lot worse. The step-up ping is not triggered by any of the kinds of actions (or inactions) you might assume. If you have a dashboard embedded on your home page, for example, the viewing of that page does not trigger the ping. Instead, the dashboard component on that home page shows a rather scary error message. It's small in the screenshot, but it says: This page has an error. You might just need to refresh it. [Unhandled PromiseRejection (check your browser console to find the code that isn't handling the error 'Uncaught (in promise)': {"message":"An internal server error has occurred\n\Error ID: 1017770241-73650 (598350221)"}] Super helpful, right? Reloading the page or clicking on the component does not trigger the ping or make the dashboard load. The only way to trigger the ping is to click on the Dashboards or Reports tab. Even clicking on a direct link to a dashboard or report doesn’t do the trick. You have to click on either the Reports or Dashboards tab to get the ping. But clicking on those tabs is going away from where you want to be. After going to those tabs, you can go back to the Home page and it will load as expected. It seems like an extreme understatement to say that is an unintuitive click path. Consider the situation of an executive user. Perhaps this is the executive director of your nonprofit. Or perhaps it’s the CEO of a multi-billion-dollar company. The helpful admin knows that this leader is only going to use Salesforce to get big picture information. (If we can get them to ever log into Salesforce at all…) So she has created an app (really just a single Home tab) tailored specifically for them: it’s got a single dashboard embedded in it. Today, when the exec logs in, they enter username and password, tap Allow on the MFA challenge on their phone, and within seconds see the dashboard that tells them all they want to know about the financial situation of the organization. Awesome! Maybe they don’t love the MFA challenge, but they live with it because they understand that it’s there to keep their company’s data safe. But by July 31 the executive app simply will not work at all. They’ll log in only to be greeted by this screen. None of the likely actions they might take (reload, log out and back in, etc…) will fix it. And nobody, to my knowledge, has any kind viable workaround. I can articulate a click path that will allow that executive to view their dashboard: Log in > Complete MFA > Click on Dashboard tab > Complete MFA again > Click on Home tab or on name of dashboard. That’s not a reasonable series of clicks. And the executive is never going to follow it. They’re just going to conclude that "Salesforce is broken" or it's useless (or both) and never bother to log in again. [Pissing off an executive, I would argue, is not so much my problem, nor even yours, dear reader. It is a problem for Salesforce as a company. For years we’ve talked about dashboards and an executive-focused app as a great strategy for building an executive champion. The step-up authorization, as currently built, is going to torpedo that tool. Update 6/10/2026 Salesforce has officially confirmed that this should not be the behavior and that embedded reports and dashboards on a Lightning page will not trigger a step-up ping. A patch is rolling out to sandboxes and the behavior when it goes live in production orgs should not be as bad as it was when I tested this. Hopefully other improvements will also be coming. But considering the short timeline and the pressures on the programmers, I couldn't speculate on the schedule of those changes. Ask for a temporary reprieve! Apparently at least one consultant (who will remain nameless for now) asked Salesforce Support how to keep his integration from breaking and was told that his client could request an extension of the deadline. I think we should all ask for this! All you have to do is open a case with support requesting a delay of the enforcement of step-up authorization to view reports and dashboards. You probably need to include a business justification. I suggest, "Because if you implement it as currently designed my organization will stop being able to use Salesforce on the day of enforcement." You can stop reading now 🛑 If you are only interested in the high-level overview, you can be done with this blog post. I’ve made my point about how terrible this is going to be and hopefully you’ll hear from me later that Salesforce has fixed things. Sorry I don’t even have a workaround to offer you. But if you want to understand more of the details, keep reading. Why SSO is DOA for MFA As I understand it, one of the most confusing and challenging things about the step-up security requirement is that single sign-on (SSO) actually makes for a worse, not better, experience. Presumably your SSO provider counts as MFA—and even phishing resistant MFA—so you’re in compliance with the security requirements there. But since that MFA is not one that was triggered by Salesforce it can’t be used to set the flag that starts a step-up security session. This is a double whammy. First of all, it means that users who have just logged in via SSO are going to get the second ping even if Salesforce were to fix the situation for direct logins through username, password, and Salesforce Authenticator. But I think this also means that users who log in via SSO and have not, to this point, had to even set up Authenticator, will now have to add that for viewing reports or get a ping via email. I’m sure users are going to love that. This Feels Like Lazy Programming I don’t want to be too harsh on Salesforce’s employees here, but it really feels like this is being implemented without any thought to user experience, too quickly, and with no testing. For direct logins where it is Salesforce’s own platform triggering the MFA, the initial MFA challenge should count for the first two hour session. [Clearly!] How is an MFA ping seconds later more secure than the first one was? Perhaps someone from Salesforce can articulate a technical reason here. Given the other ways recent security changes have been rushed and poorly communicated, I just can’t give the benefit of the doubt in this case. I will give credit that the SSO case is harder. To the extent I understand it, I get that the technical triggering of the MFA through SSO is outside Salesforce’s control and, therefore, perhaps, they’re not willing to consider that step-up. But if it can count as phishing resistant and good enough security for an admin to log in, it seems very strange that wouldn’t be good enough to view dashboards. What I really think is lazy programming is the situation I described above, where an executive user simply won’t be able to use Salesforce at all. Either Salesforce didn’t figure this out in testing or they think it’s acceptable user experience. [Spoiler: It’s not acceptable UX.] How could they have done literally any functional testing and not run up against this limitation? I noticed it in less than a minute. It took me about four more minutes to confirm the situation, create screenshots, and post about it to ask if I was understanding it properly. Is Login As dead? As of when I’m writing this on June 2, the ability of admins to Login As a particular user is also broken by the step-up verification. If you login as someone else and then take an action that triggers step up authentication, the ping goes to the user you are logging in as. This makes Login As essentially useless as a tool for admins troubleshooting anything report or dashboard related, since you would have to be doing it in real time with the user. We’ve heard Login As listed as an item for fix in the coming patch, but no details on that. So as of the current moment, admins are going to be essentially unable to troubleshoot report viewing issues. Shared Logins and Things like GConnector/XL Connector Are Toast As far as we can tell, any kind of shared login to run reports is non-viable at this point. If you rely on apps like GConnector to export data from a Salesforce report to a spreadsheet so external partners or non-Salesforce users can see it, this isn’t going to be able to refresh on a schedule. The user that the GConnector logs in as might be able to manually refresh after step-up, but this isn’t clear right now. I’m passing no judgement on this front. Maybe this kind of process has been too much of a security hole for years. But the fact is that lots of organizations use reports to facilitate different kinds of processes or integrations and it looks like those are going to break. Help us!!! 🛟 It’s really too bad TDX passed before this was announced and Dreamforce doesn't happen for several months. If there was a True to the Core session I would be first in line to ask a question about this. (The room would erupt in supportive applause.) But if these changes go into effect on the current schedule, then TTTC at Dreamforce will be far too late. Extreme damage will have been done. This blog post is my cry for help. I’ll be happy to volunteer to be part of the solution. Presumably that means doing testing and giving user feedback within a very compressed time frame. I’m sure there are a lot more of us that will also raise our hands, both MVPs and many more members of the community. To be clear: this is not our job. Nor is it the job of anyone that doesn’t get paid by Salesforce. We are willing to do this because we want to make things better for our users. Salesforce ought to be paying their employees to do this right the first time.

Unless you've been willfully ignoring the panic-inducing messages from Salesforce, you've probably gotten an inkling that sometime this summer admins are going to be required to authenticate using "phishing-resistant" multifactor authentication (MFA). Most importantly, this means admins will not be able to use the Salesforce Authenticator app, you'll need something stronger.. Everyone else in your org will still be able to use Authenticator (or equivalents), but not admins. In fact, if you haven't already been requiring it (and you should be), they're going to be forced to use MFA from now on. There are some other changes as well, particularly that people will be forced to re-authenticate themselves before taking actions that could be used for mass exfiltration of data, like running or exporting a report. It's the admin MFA change that's getting the most attention, though, and for understandable reasons. Enormous amounts of "ink" have already been spilled in discussions so I don't think it makes sense for me to rehash the whole issue. If you are interested, you won't have trouble finding threads on Ohana Slack, Trailblazer Community, or the Partner Community, I have no doubt. (I've been in at least four overlapping conversations in different channels.) And if you're not that interested, that's OK too. You just have to make sure you (or your org's admin) take the required steps to avoid any difficulties. I'll make those steps clear below. Who's an Admin? In case you were wondering, the "admins" that will need the elevated MFA are defined pretty much as we would expect. Without any intent to make a comprehensive list and acknowledging that Salesforce could change this, they're basically saying it's going to be either those on the standard System Administrator profile [Duh.], or those with the permissions Modify All Data, View All Data, or Customize Application. (It's my working assumption that those are OR, not AND conditions.) I don't know if they mean anyone who has a profile with those permissions or if getting those permissions via a permission set also ups you to needing phishing-resistant MFA. If you're reading this blog, how about we just assume this is going to apply to you? Pain for Partners I want to give credit to Hayley Tuller for writing a great summary of the phishing-resistant MFA issue. As she notes, this change is going to be particularly difficult for consulting partners. It's been standard practice for years that those partners would share a login by storing credentials in a shared vault (like LastPass or 1Password), which could even handle sharing the MFA. It's much easier (and more cost-effective) than expecting the client organization to dedicate a full license for each employee of the consultancy that might need to log in to help with some admin tasks. That looks like it's going to be impossible going forward. Organizations will have to either figure out activating and deactivating licenses or Salesforce may need to work out a consultant licensing situation similar to the free integration users. The latter idea, if it were even considered, would take time for the company to implement. So change is coming, and quite soon. Fortunately for me, as a solo consultant, this won't make a difference. I have individual named licenses in each of my client orgs. (And in the cases where I use subcontractors, so do they.) But I certainly understand the challenge this will present for consultancies. I assume that any employee of Salesforce that gives it a moment's thought also recognizes this particular part of the challenge. But the company, in all of their communications to date has resolutely refused to acknowledge how this will affect partner operations, much less hint at any strategies to mitigate the disruption. That's not winning them any hearts and minds. A Few Easy Steps Let's turn now to what you need to do. It's really not that hard. Prerequisites You are going to be creating passkeys, a cryptographic key that is stored on your device (or in a secure vault) so it can't be stolen. This means that you need a way to generate a passkey and a place to store it. You almost certainly have this either built into your computer and operating system or through a password manager app. I am on a Mac and can easily create and store passkeys in the Passwords app, which stores them in Keychain. Your situation may be different, but mostly in name. As far as I can tell, you do not need a biometric authentication device to be able to create a passkey. So don't worry if your computer doesn't have a fingerprint sensor or the ability to log in with your face, like your phone can. I verified that I could create a passkey on my Mac Mini that uses a keyboard that does not have a fingerprint sensor. Enable Built-In Authenticators This one is barely worth me writing it out because the relevant Help article is short and to-the-point. But I won't make you navigate away: Go to Setup> Identity> Identity Verification. (Just type "identity" into the Quick Find.) Check the box next to "Let users verify their identity with a built-in authenticator such as Touch ID or Windows Hello." Note: If you want to let people use a physical security key (often called a "Yubikey," though that's just one brand), this is the place to enable that. It's the setting right below. Save the settings. Register a Built-In Authenticator for Yourself Again, there's a Help article about this, but it's longer and harder to skim. So: Go to your personal user settings. You can get to these settings in either of two places: From the front end of Salesforce, click on your profile picture (or Codey's face, if you haven't uploaded a picture)> Settings> Advanced User Details and scroll down (or use the quick links at the top) to Built-in Authenticators. From within Setup, go to your User record. Scroll down (or use the quick links at the top) to Built-in Authenticators. Now click Add. You'll get an MFA challenge from your current MFA method (presumably Salesforce Authenticator). Then follow the prompts to create a passkey, name it, and save it wherever you store these kinds of things. (I store mine in Apple Keychain.) Note: I chose not to include screenshots of the process for registering and saving a passkey because I have to assume those screens look a bit different depending on browser, operating system, passkey vault, and maybe even other factors. For me, on a Mac with Touch ID, the process was pretty self-explanatory. I expect it's pretty clear with Windows Hello as well. And one more note: I did this process with my Macbook closed the whole time and I have an older external keyboard that has no Touch ID sensor. So while I was "using a Mac with Touch ID," I never actually used a fingerprint sensor. Moment of Truth This is the panic moment: Log out. Ensure that you're able to log back in. If you're not the only admin at your organization, you might give the other admin(s) a heads-up that you're doing this so that if you get locked out, they're available to help you. You shouldn't have any problems, but it can't hurt to have a backup plan. I went through and did this for myself for all the orgs I work with several weeks ago. It took probably less than two minutes per org, including logging in, making the Identity Verification change in Setup, registering my new passkey, logging out, and then logging back in. What's Different? Your setup may vary, but I've actually found this to be much more convenient than Salesforce Authenticator. I no longer have to fish my phone out of my pocket to verify a login nor to wait for the location-based auto-approval (when it works). I can do it all on my computer. (And when my laptop is closed because I'm plugged into an external keyboard and monitor I don't even have to use Touch ID or take any action other than a click. That seems odd to me, but I'm not complaining!) Unknowns I don't know what will happen when it's time to get a new device, if my laptop dies, or I just decide to upgrade. My recollection is that Salesforce mentions device-specific passkeys. (See Haley's article for more on this.) As of this writing, I can confirm, after trying this a few times, that I am able to log on from my "personal" Mac Mini to an org using a passkey that was generated on my work laptop and that is stored in my Apple Keychain. So at least for now (and maybe this will change with the restrictions that roll out in July, or maybe it will change at any moment) the passkey was able to be used on a different device, as long as that device was logged into my same iCloud account, thus giving it access to the passkeys in my Keychain. I'm not a security expert, but that actually feels pretty reasonable to me. I would very much appreciate it if Salesforce kept this state of affairs. I definitely have a fear that even though it's stored in Keychain and in some way "available" across all my Apple devices, Salesforce passkeys will stop working from a different device than they were created on. We seem to have gotten some confirmation from Salesforce that they are going to allow stored/synced passkeys like this. But I would call the confirmation provisional or not-guaranteed, for the moment. So if (or when) it becomes the case that passkeys can't sync across devices, I think that would mean that to migrate to a new computer I would need to un-register the passkey while logged in from my old computer, then log in on the new computer, then register a new passkey. Or maybe it will be possible to register a second one (on the new computer) and then subsequently delete the old one? Surely you'd need to be able to do something like this if you regularly worked from more than one computer...? All this is to say that passkeys could make transitions to a new computer more challenging, especially if your transition is sudden, like if your laptop is run over, or stolen, or you pour lemonade on it during a Community Sprint... In that case, you may need another admin to go to your user record and unlink the built-in authenticator so that you can start fresh. (Similar to what happens when users get a new phone.) If there's no other admin available, you'll probably need help from Salesforce Support.

Thanks to a post on Ohana Slack I learned recently of a new setting that Salesforce quietly slipped into the back end and defaulted to ON. Unless you have been ignoring the news recently, you probably won't be surprised that this new setting relates to AI. Specifically, the setting allows Salesforce to access "customer data" to train AI models. If you're wondering what "customer data" entails, Salesforce never directly specifies. That, to me, means they define it as “the values in every field on every object, custom or standard, that you have in your org.” In other words, they are going to use all of your data to train AI models. Ask yourself who owns or will own those models? [Hint: It's not you.] Setup > Opt Out of Customer Data Access You can find the setting at Setup > Opt Out of Customer Data Access. When you get there, you'll see that it is ON by default. If you don't like this (And I don't!), Move the slider to turn it off. You even have to endure an "Are you sure?" screen. Click again to confirm. As soon as I learned of this I logged into each of my client orgs and turned it off. The Clue Maybe you're wondering why I have made such an unfavorable assumption about how Salesforce has defined "customer data"? Well, if you follow the help link to "Learn More" at the bottom of that setup page, it specifies in which situations this setting is defaulted to ON. It's not defaulted for Government Cloud instances nor if your organization "has decided to opt out, or has previously opted out, of sharing Customer Data with Salesforce." More Nuance I was pointed to this help article for a little more explanation of the setting. And I understand that, particularly for predicative AI, most organizations aren't going to have enough of their own data to train models. So I can understand the argument for there being a benefit to training global predictive models. I actually wrote in 2022 about trying to use Einstein prediction builder and the fact that few orgs have enough data to develop predictions on their own. I will also note that this setting "doesn’t affect Salesforce’s zero-data retention (ZDR) policy with third-party Large Language Models (LLMs)." So [at least for now] this setting is only about training predictive AI and not about training generative AI. If you read my follow-up article about Einstein Prediction Builder, you may remember that I didn't find it that useful, even using the "pre-built models" from Salesforce. And ask yourself if you've heard anyone else talking about Einstein Prediction Builder in the last several years? The freemium version of Prediction Builder also looks like it's gone away. So is there even any benefit to us if Salesforce works on these models? Or does the benefit mainly accrue to the company that will come around trying to sell them in the future? A Violation of Trust Regardless of how hard it might be to build good prediction models, that does not justify taking your organization's private data without affirmative consent and without compensation. Salesforce constantly touts Trust as their "#1 value." Dropping a new privacy-piercing setting into your system and defaulting it to ON feels like a major violation of that trust. I also just don’t like the idea of handing over my nonprofit clients' data to train a model that is going to make billions that won't benefit nonprofits. UPDATE later in the Day 4/29/2026: Salesforce has apparently heard the outcry about this setting. They responded (on MVP Slack, but I confirmed that it's OK to share) with this statement: We know questions have been coming up lately about how Salesforce handles your data, and we want to take a moment to address them clearly and honestly. Your trust matters to us, and we want to make sure you have the full picture. No New Enrollment Has Occurred Salesforce has not recently opted customers into any new data-sharing program. For applicable core services, the ability for Salesforce to access Customer Data has historically been permitted by default under your legal agreement — unless you use Government Cloud, have previously opted out, or have otherwise restricted access under your agreement. What Actually Changed We heard your feedback about wanting more visibility and control. Eligible customers can now view and update this preference directly in Setup under Opt Out of Customer Data Access — without needing to contact Salesforce Support. We believe you should always know what settings exist and have easy access to manage them. Frequently Asked Questions What is this setting used for? This setting gives Salesforce permission to use your Customer Data (as defined in your Main Services Agreement) for three specific purposes: training global predictive AI models that power features you use, improving existing services and features, and researching and developing new ones. Is Salesforce using my data to train generative AI or third-party LLMs? No — and we want to be completely clear on this. This setting does not affect Salesforce's zero-data-retention policy with third-party LLMs. Salesforce has committed that any generative AI model training would only occur on an opt-in basis, and no such program has been implemented. Why is this allowed by default for some customers? Default access supports the services and features you rely on every day. We understand that "default on" can feel unsettling, and we want to be transparent: data from opted-in customers is always subject to Salesforce's full confidentiality and security commitments and is never directly shared with other customers. Can I opt out? Absolutely — and we fully support your right to do so. You can turn off Customer Data sharing at any time in Setup via Opt Out of Customer Data Access. Once disabled, no new data is shared for these purposes. For service improvement uses, any previously collected data is deleted within 30 days and cannot be recovered. Credit where credit is due: This seems like a fair and reasonable response and a fair and reasonable way to handle the issue. Salesforce is acting no worse than most of their peer companies. (I could wish they were acting better than their peer companies. But I'm realistic.) Bottom line, though: Now that I and my clients have a way to opt out, I'm gonna do it.

A while back I wrote about a solution I built, using Flow, to solve the annoyance around user ownership of a File when you want to delete it. You probably won't be surprised that's not the last time Files have given me a headache. (Same client, in fact: For Pete's Sake, a great little organization.) As usual, this was a totally reasonable request. They wanted to include a scan of a lovely handwritten Thank You Note created by the family on respite and send it to the doctor that nominated them. Hat Tip to Andy Utkan for this blog post on Salesforce Break that helped me understand how to make this happen. Hide and Seek First step: I have to find the file in question. Good news, I know where it will be! It's uploaded as a File attached to the triggering record (of a custom object called Respite) that fires our record-triggered flow. We even have an agreed-upon naming convention to ensure that the thank you note is distinguishable should there be other attached files: the staff upload with "TYN" in the name. Shouldn't be too hard, right? Nope. Guess again. We're talking about Files in Salesforce, or, as I think of it, the ContentWhatever architecture. There always seem to be at least four objects involved! Plus there are special [Specially annoying!] ways you can't work with ContentWhatever in SOQL. To add insult to injury, for some unfathomable reason, I can't even find an ERD (entity relationship diagram) to try to understand the ContentWhatever system visually. Poke around the developer documentation for a bit and you learn that ContentDocumentLink is what attaches a record to a ContentDocument. But don't forget about ContentVersion! I know you care deeply that Salesforce handle file versioning for you. And while we're at it, notice the special note on that page about how queries won't return all files a user has access to. See what I mean about SOQL for ContentWhatever? Add in some trial-and-error and I confirmed that the Send Email action is going to need the Id of a ContentVersion to use as an attachment, not a ContentDocumentLink, not a ContentDocument. So we have to find: A ContentVersion of a ContentDocument, whose name contains "TYN," that is connected via a ContentDocumentLink to our triggering record. Thankfully, it's safe to assume there will be one and only one. (Or at least we can just use the most recently created one.) But we can't just do a Get Records with anything like that list for filters—oh, no, that's not how ContentWhatevers roll. Can't do it with a simple SOQL query either, so UnofficialSF's Execute SOQL action for Flow won't save us. How To Solve It Taking basically all the steps in Andy's blog post, I had to: Get all the ContentDocumentLinks where the LinkedEntityId = our triggering record. Transform that collection into a list of ContentDocumentIds. Get the the ContentDocument whose Id is IN the list of ContentDocumentIds AND whose Title CONTAINS "TYN". (We narrow it down to only one by sorting by created date and taking only the newest.) Check to ensure that a ContentDocument was found. (Because your email will error if you try to send with an attachment but have none to attach.) Use the LatestPublishedVersionId from the found ContentDocument. {!SecondGetRecordsStep.LatestPublishedVersionId} Yes, that's a surprising number of steps. It looks like this in the relevant section of the flow: Then on the branches after the decision we either send an email with an attachment and language about it or a version that has neither.

I recently had problems in two different client orgs where users found evidence that a screen flow wasn't working. Different screen flow. Totally different set of actions it was supposed to take. But the users noticed that emails apparently weren't sent. Or fields weren't updated. And these were both screen flows that had been thoroughly tested and had been in use for months, if not years. I'll give you a screenshot of one of the screen flows that had the problem. Click to enlarge, if you wish, but there is no need to pay attention to the actual details of this flow: Here's a simplified representation of how most screen flows work, and plenty representative of that one: To list it out, it goes like this: Get some records (or do other logic). Present a screen to the user. User clicks Next. Do some logic based on the user input. Present another screen to confirm for the user what is about to happen. User clicks Finish. Do final actions and logic. But can you spot the major flaw? I would estimate that at least one in ten runs of this flow will do absolutely nothing. Hints: It has nothing to do with any of the component settings. Fault paths would not help. Did They Finish? The problem is that the actions in step 7 take place after the user clicks Finish. It's subtle, but think about it for a second: What if the user never clicks Finish? Yes, it's a big, bold, tempting Finish button. And I've been known to use language like "after you click Finish..." to describe what's about to happen. But there is still a non-zero chance that the user will abandon the screen flow as soon as they get that final screen. They could click away from it to elsewhere on the page. If it opened in a modal, they could click the X to close the window. (I'm sure there are other creative ways that haven't even occurred to me.) And it's virtually impossible to actually track this—there's no logging of the action a user didn't take. I guessed that this was happening in both cases of my clients whose screen flows "stopped working" and when I asked the users in question, they admitted it was likely what had happened. The Fix: Finish Before Finish This is clearly easy to resolve. Just move all the actions of your screen flow to before the point where a user would expect they have already happened. There are always going to be reasonable use cases for launching a screen flow and then canceling it, of course. But at any point that the user might think the flow has acted, you need to make sure it already has. So for my simplified flow, edit to look like this: On the real flow, I just had to move a few things around at the very end. This, with the Update Records step at the end: Became this, where the update is complete before the final screen: I've pretty much come to the conclusion that the last screen in a screen flow should always be the absolute last thing on the canvas (other than a Navigate Everywhere component, perhaps). All actions and logic take place before it looks to the user like the flow is complete. That might mean I have one more screen, so they have a chance to consider an action before clearly clicking "Take Action", and then at the end they get a confirmation screen that's just window dressing.

Our beloved community of nonprofit Salesforce practitioners needs to have some deep and important conversations. And not just in little one-on-ones or side notes to other discussions. I'm not sure who all the right voices are to include. I've failed, so far, to bring interested parties together. And, let's face it: my voice, in particular, might be more of a distraction than a help. Besides, I'm not sure how, when, or where to convene these discussions. But in case it's helpful, I can articulate the What and the Why. What: the future for nonprofits using Salesforce What we need to discuss, in case you haven't figured it out from my previous posts, is on the future for nonprofits using Salesforce . At the moment, we've got potential for quite a bit of chaos when nonprofits look at adopting Salesforce (or those already on the platform consider the future of their instance). Five years ago a nonprofit about to adopt Salesforce was overwhelmingly likely to use the Nonprofit Success Pack (NPSP). The few that didn't choose NPSP had specific reasons, like an earned-revenue model where Sales Cloud was right for them, or a plan to use another specific app. Functionally, this meant that when we spoke about "nonprofits on Salesforce" we were talking about NPSP or at last orgs that have NPSP as a base to other customization. But since the launch of the Industries-based Nonprofit Cloud (now "Agentforce for Nonprofits" or "AFNP") we have already seen a bifurcation of the market for new instances. Of course, the vast majority of the installed nonprofit base is still on NPSP. But Salesforce is selling AFNP hard , for all kinds of reasons (including, but not limited to, profit margin). And, starting in December, Salesforce has even removed the option of getting your org provisioned with NPSP pre-installed. [For the record: You can still get NPSP with your new P10 donation. You just have to install it .] From the very launch of Nonprofit Cloud people realized it was going to have ... How shall I put this? ... gaps. That is to say, there were things that were too complex, or confusing, or poorly documented, or components that didn't work well . I was there for the initial conversations that lead to the NPC Best Practices group of the Open Source Commons. Kudos to them for the work they've done and are still doing toward making AFNP more understandable, easier for admins (and consultants) to set up, and just more usable for more organizations. At the same time that Salesforce is pushing AFNP and NPC Best Practices is working to speed up its maturity vis-a-vis the marketplace, others are deciding that the Industries- and person accounts-based model is just not a good fit. Besides me, there isn't much public writing about this for many reasons (but mostly money). But consultants have conversations with their clients. People have conversations at user group meetings, on the margins of various events, and one-on-one all the time. People are even stepping into the breach to offer products on the platform with the kind of functionality NPSP offers, but without the dependency on support from stock ticker CRM. Idlewild has been publicizing their Nonprofit Accelerator (NPA) and thinking about how to make it available more widely than just to their clients. I raised a question at the 2025 Denver Community Sprint that become the Nonprofit Bridge project. And recently Laura Meerkatz forked NPSP's code to create a new community-owned version called NPPatch . There are almost certainly other efforts happening that I haven't heard about yet. (I've also heard more than a few consultants asking the question, "Are there other CRM alternatives that I should recommend for clients of my size/type?") On the one hand, these three projects are great! This is a revitalization of the community. It shows a level of interest and commitment that I applaud. It sounds like the kind of energy that created NPSP in the first place, before Salesforce.org took it over. On the other hand, we're duplicating effort and we're neither coordinating nor communicating. We haven't answered questions like: Do we (as a community) want/need an alternative to AFNP? If so, is NPSP still that alternative? Or NPA? Or NPPatch? Or should Bridge build something of its own? Are we OK with having two "camps" (AFNP and NPSP), or three, or four? Who should own, publish, and support the product(s) that nonprofits adopt? Major kudos to Laura for opening discussions  on her repo about exactly these questions. But she hasn't gotten much traction there yet. (And maybe the Discussions tab of a GitHub repo isn't the right place. Plus it’s the discussions of a specific repo.) Bridge got a lot of interest in Denver and many people signing up to its LinkedIn Group . But more enthusiasm than discussion. And Idlewild initially started to launch a partner program for NPA in the fall, then put that on indefinite pause for internal discussions. So these conversations are just not happening yet. Why: the future for nonprofits using Salesforce [See what I did there? The What and the Why are the same thing!] These conversations are important because they impact the very idea of whether nonprofits will continue to use Salesforce in similar enough ways that we can have a "nonprofit Salesforce community." As long as it continues to be "free" for nonprofits, there will be organizations trying out this platform. But if they're all using different configurations, then they'll only have similar challenges (like how to raise money, how to engage constituents, how to track outcomes) but not similar solutions to share. Start the Conversation! Sticking with my normal every-two-weeks schedule, this post is going to go live the morning before Nonprofit Dreamin 2026 . That's coincidental but very fortuitous timing. Lots of nonprofit Salesforce practitioners will be in the same place. Some of the leaders of the projects I've listed will be there as well. I'll be there. I'm sure a lot of you, my readers, will be there. Let's talk. And when the conference is over, let's continue talking on the Trailblazer Community, on Ohana Slack, at TDX and Dreamforce, and Dreamins, and sprints, and everywhere else.

There are all kinds of scenarios in which we find ourselves with a list of people that we want to add to a campaign but we know the list includes a mix of existing Salesforce contacts and people that might be in the database yet. Happens all the time, right? Maybe you get a handwritten sign-in sheet. Or someone emails you the list of people they want to add to an event. Or you're combining lists from several people. In this situation, what we really want to do is an “upsert” of contacts (Upsert means “ up date them if they exist, otherwise in sert them as new records.”) and also add those contacts to a campaign. I suppose, depending on what we're doing, the campaign might already be in Salesforce or we need to create it for this import. Let's assume the simplest scenario: We have a simple sheet of people that includes three columns: First Name Last Name Email In addition to those three columns, there are two additional pieces of information we presumably have, either on the spreadsheet already or at least in our head: Which campaign we want to add these people to. (Either we know the campaign exists in Salesforce or we know it does not and we want to create it.) What campaign member status each person should end up with after this import. We also know (or at least suspect ) that the emails on our spreadsheet might be a mix of the values we have in the personal, work, and alternate email fields for our existing contacts. ( Because the world is just fun like that! ) With only access to regular import/export tools we would have to work on this in multiple steps. Download a list of contacts and use vlookup to find Salesforce Ids for those that exist. Then insert those that don't, get their contact Ids and add them to the spreadsheet. Then import a list of campaign members for all the Ids. What a pain in the butt! NPSP Data Import Object to the Rescue! Usually only used for the initial data load to a new implementation, the NPSP Data Import object  is really handy for this need! If you're working in an NPSP instance (and most nonprofits are), you can do this in just three simple steps: Load records of the NPSP Data Import object from your spreadsheet. [Optional] Do a dry run of the processing of those records. Process those records into the database, creating contacts, campaigns, and campaign members. 1. Load to the NPSP Data Import Object NPSP Data Import is a simple holding object. It has many fields on it that correspond to fields on contact, account, opportunity, campaign, etc. Records of this object do nothing special, they just wait to be processed to become multiple records. In the case of our spreadsheet, use whatever upload tool is handy to end up with one NPSP data import record for each row of the sheet. Those records will look like this, with values in Contact1 First Name , Contact1 Last Name , one of the Contact1 email fields, plus Campaign Member Status and Campaign Name . If you use Campaign Name, expect Salesforce to either match on that campaign name (Exact match!) or to create a new campaign with that name. If, on the other hand, you want to select an existing campaign, just fill out the Donation Campaign Source lookup field (highlighted with a red rectangle). An important note about Campaign Member Status : The Campaign Member Status field on the NPSP Data Import object is just a free text field. There is no validation that the values you use here will match the campaign member statuses of campaigns in your instance. The importer will create campaign members with whatever status(es) you give it. So be careful to only have values in your spreadsheet that match the values you normally use. "RSVP Yes" is different from "RSVP Y" and from "RSVP-Yes" and from "RSVP - Yes". They're subtle differences, but if you aren't consistent with your campaign member statuses, they can be annoying ones! 2. [Optional] Do a dry run of the processing of those records. Now that you have several NPSP Data Import records created by your import, you can go to the NPSP Data Imports tab. There, you'll see all the records that are ready for processing. The Import All Data Import Records button will bring you to the NPSP Data Import screen. Though optional, it's generally recommended to do a dry run before your final import, which allows you to see how the system would match or create records. 3. Process Records Into the Database Once you're confident that things are going to go smoothly, just go back to the NPSP Data Import tool and click Begin Data Import Process, which will do the final processing of your records into the database. Contacts are upserted (matched or inserted) and added to the campaign, which was itself matched or inserted. How cool is that!?! Other cool tricks: So. Many. Fields. I only talked about three data fields (first/last/email). But the NPSP Data Import object has fields for multiple emails, salutation, title, preferred email, preferred phone, account data, and much more. You can also use the object's power for a whole lot more than just adding people to a campaign. See the full documentation . You don't have to work on only one campaign at a time! Though I wrote this post focusing on a sheet of people to be added to a single campaign, you aren't limited to that. Put in some people with one campaign and others with another and you'll end up with two campaigns populated at once. Nice! Unduplicated Contacts Go ahead and put the same person on two rows of your spreadsheet with different campaign names. The data importer will not duplicate the contact, but it will put him into two campaigns (with different statuses, if that's what you had on your import).

Well, Marc Benioff managed to do it again . If you thought his interview in October was bad, now you don't have to wonder if it was a one-off. This time he asked international employees (that his company had just flown to Las Vegas) to stand, as though they were about to be recognized positively, then "joked" that ICE was waiting in back for them. Into the deafening silence from the company, Parker Harris eventually said that he was "not OK" with Marc's comments. That alone would have been too little and too late. But he followed up by basically threatening employees that speak out about this with firing. Sigh. I don't have much more to add here than has already been said better than I could in LinkedIn posts ( here , and here , there are many more), threads on Slack channels, and the like. But I decided that I don't want to just ignore this either. I owe it to the Salesforce employees and the broader community—actual feeling humans, regardless of whether they were born in the US or abroad—to use my platform to say two things: This is unacceptable. It was insensitive, mean-spirited, and truly shows us just how disconnected tech bros are from real people. I think the board ought to remove Benioff over this. I actually think this may be grounds for just about anyone to claim that Salesforce is a hostile work environment. I hope someone sues. Salesforce should be punished for this kind of behavior by its CEO. (And Wall Street ain't likely to do it.) Benioff Said This, Not You To employees of Salesforce: I feel for you. I sympathize with what you must be going through. I can't really imagine how crappy it must feel to work for someone so hateful. There are many of you that regularly interact with the community. I think you do it with respect. I've found most Salesforce employees to lead with compassion, humility, and understanding. Thank goodness you're not learning from the example of your CEO! I'm sure that since this happened, some of you are taking heat that you don't deserve. I don't claim to speak for anyone but myself, but I hope you know that we in the community have your back . If you need (or want) to stay in your job (for all kinds of reasons), that is OK. If you feel you need to quit over this, I will be here to support you in whatever ways I can. I Wish I Could Do More It would be nice to think we could really punish the company for keeping Benioff in leadership after comments like these. I just don't see many avenues that I think would be effective. The stock market has been punishing the company's share price for more than a year. No one could truly say if any recent drop has to do with the recent mess. But trusting Wall Street and capitalism seems rather naive to me anyhow I'd love to see people boycott Salesforce's signature events like Dreamforce, TDX, and World Tours. But again, it's hard to know how this would truly send a message, since there will always be some people attending (they need to for their business) and the motives of those not there are rather hard to measure. I can tell you right now that my heart wouldn't be into going to any of those events right now. But I'd cooled on the big events already because I think the community-organized not-sponsored-by-Salesforce Dreamin events are so much better for learning and networking. And then there's the question of using the platform or not, recommending the platform to a new nonprofit that needs a CRM or not. Unfortunately, as I've written before , I don't see a viable alternative. I'm using a technology because it works and I'm supporting my clients that are already on Salesforce. I'm not going to pretend that the company behind the platform somehow is also improving the world.

Today I'm offering a quick gift. Nothing fancy. Nothing a lot of you wouldn't already know. (But I've found a good number of admins out there that haven't discovered this yet.) You know that annoying little notification at the bottom of the Flow Builder canvass every time you work on a flow that always has a notification bubble on it? In case you need a reminder, I'm talking about this one: The one that is always pestering you about not having pink elements within a loop. Even if you don't have a loop! ( Here is a brand new flow with no elements on the canvas at all, much less any loops: Please explain to me why it's already got a tip for me.) Have you noticed that the tips rarely have much by way of useful advice anyway? I know you've seen this box. I know you probably are annoyed by it. If you're like me, the fact that it has a notification bubble draws the eye and the fact that you can't dismiss the notification is infuriating . Today I'm here to tell you that you can make it go away. ?>Mute Tips The function you're looking for is called "Mute Tips." Simply click on the question mark help menu in the upper right of the Flow canvass and select the last option, "Mute Tips." Gone! Just like that! And this selection will persist. So the next time you open this or any other flow, no more annoying notification bubble! Hooray! 🥳 🎉 Unfortunately you'll have to do this fresh in each environment. The next time you spin up a sandbox to work in a new flow you're going to have to mute the tips again. But at least you have the option. Unmute Tips if you Desire If, for some reason I can barely imagine, you decide you want the tips back again, you can unmute them in the same place. You're welcome.