Search Results

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.

It's quite a while ago that I wrote about having test data in your production org . ( I'm still a fan.) But recently I set up an additional way to work with those test records: formula fields that designate a record as part of your test suite. My client For Pete's Sake (FPS) really needed this trick. FPS has quite a few contacts that are test records and they come from various franchises or no franchise at all because they've been created by different people at different times for slightly different reasons. That makes it pretty hard to keep track of them all. Let's just list some of who they have: Patient Homer Simpson, his wife Marge, and children Lisa, Bart, and Maggie . They went on respite several months ago. Homer and Marge share phone numbers with a couple of FPS staff so that we could test notifications asking them to complete pre and post respite surveys. Patient Wonder Woman and her caregiver Spider Man went on a later respite. They, too, shared phone numbers with real people. Micky and Minnie Mouse have also gone on respite and filled out surveys. There's a doctor Frank Enstein who has nominated some of his patients for a respite from FPS. ( That one still makes me giggle. Kudos to Pam, the FPS staffer that came up with it. ) On quick glance in a report or list view he is not obvious as a fake! The Flintstones are in there. And then there are Im Testingagain and Atest Nominator, both of whom I get the blame for. (I wasn't feeling creative by the umpteenth iteration of testing a FormAssembly form.) Etc... We created several of those patient and family groups in the fall, when FPS was testing a new mobile app they'd launched for patients and caregivers that includes their surveys. We needed to be certain the SMS notifications were going out and that surveys completed in the app flowed through the integration to Salesforce. And then we needed (and still need) to keep those test patients going so that we get the follow-up surveys at 1 month, 3 months, 6 months, 9 months, and 12 months post-respite. We can't restart and reuse those same people as though they're newly nominated or we'll lose our test of the ongoing follow ups. This also means we might add some new test records during upcoming respites if we find we want to test other things. But that's not all! For each patient in the FPS program we have onboarding records and respite records as well. Those are related to the contact by a lookup field and are auto-numbered. So even if the patient name were an obvious test record, the respite or onboarding might not be. For Pete's Sake also uses leads for the initial nomination of a patient by their doctor. So we're going to have some test records in the Lead object, either as new nominations or already converted into some of the contacts above. ✅ Formula Field to the Rescue Easiest way to know if a contact is a test record is to have a field that is automatically checked if they are. No magic here, that's just a checkbox formula called Is Test Data . There are several ways you could approach making the formula that actually controls this field. One way or another you're going to be hard coding something into this formula by which you, the human, are directly telling Salesforce that this record is a test and all others are not. I haven't been able to come up with an alternative to hard coding. And don't forget that if you add test records, you're going to have to edit this formula to account for them. What you hard code is up to you. One option would be to hard code record Ids. As long as nobody goes merging duplicates of your test records, those Ids won't change. I decided to actually hard code the names of the people themselves so the formula would be easier to read: ( FirstName = "Spider" && LastName = "Man" ) || ( FirstName = "Wonder" && LastName = "Woman" ) || ( FirstName = "Mickey" && LastName = "Mouse" ) || ( FirstName = "Minnie" && LastName = "Mouse" ) || ( FirstName = "Fred" && LastName = "Flintstone" ) || ( FirstName = "Wilma" && LastName = "Flintstone" ) || ( FirstName = "Bam Bam" && LastName = "Flintstone" ) || ( FirstName = "Homer" && LastName = "Simpson" ) || ( FirstName = "Marge" && LastName = "Simpson" ) || ( FirstName = "Bart" && LastName = "Simpson" ) || ( FirstName = "Lisa" && LastName = "Simpson" ) || ( FirstName = "Maggie" && LastName = "Simpson" ) || ( FirstName = "Blank" && LastName = "Suzie" ) || ( FirstName = "Frank" && LastName = "Enstein" ) The formula on Lead is exactly the same. I could have consolidated a bit by just using LastName = "Flinstone" because I strongly doubt there are real people with that name. But that would barely matter. Formulas on Other Objects Here's the part where you have to know your instance: Do you need formulas on related objects to know if they go with a test record? In FPS's case, the answer is Yes. We needed formulas on Respite and Onboarding because they're related by lookup, not master detail, and there are a couple of fields that could mean they're test data, if either the nominee or patient is fake. (Hopefully it's either both or none, but people make mistakes...) Onboarding, for example, has two lookups to Contact, for the nominee and their caregiver, so we have this formula field: Nominee__r.Is_Test_Data__c = true || Caregiver__r.Is_Test_Data__c =true The nice thing here is that we didn't have to hard code for the child object's formula field. We just look up through the relationship to the formula field on Contact. If the contact is a test record, we know the onboarding is too. Now Reports are Easy! All those dashboard reports that you've been filtering with Full Name not equal to Harry Potter, Super Man, Homer Simpson... are now a breeze. Just use Is Test Data equals False . No more remembering who all the fake people are. It's easy to flip back and forth to see only the test records. And it's clear for any user looking at report filters to know why that filter exists. Also a handy filter for a related list: As long as you're updating your hard coded formula, this filter keeps up. That's far easier than editing every critical report in the org to filter off the new test record you've just created! Bonus Points Want to really help your users and yourself? Put a banner on record pages to remind you that you're looking at test records. You've already got the field to conditionally display a message. So throw on a Lightning Messaging Utility banner that only shows up when the field = True. I've set up this same banner on Contact, Lead, Onboarding, and Respite. (That was four repetitive instances of the same task, but it took all of five minutes.) Future You and your users will thank you.

A few weeks ago I wrote about the distinction between platform and product . It's a blurry line (at best) with a lot of things in the Salesforce world. I think this is confusion that the nonprofit Salesforce world has been bedeviled by for a long time, particularly due to the fact that most of us use a common tool, the Nonprofit Success Pack (NPSP). I ran across a great illustration of the confusion when I was at NPSP Day Philly the first week of December. ( A great event, by the way. Watch for one near you! ) There were several people at the event that were on the fundraising and development team of a local nonprofit that is known as a place to swim or exercise. (You've heard of them...) Their organization is in the middle of a Salesforce implementation that, honestly, sounds like it's been mismanaged. I'm sure there is more going on than just what I heard from those folk in side conversations throughout the day. But the main thing I was able to gather was that at some point the person implementing basically told the fundraising team that because they had an org with the Nonprofit Success Pack (NPSP), they should be able to "just start using Salesforce" for their development work. [Not a quote, just my way of expressing what I gather they were told.] The implementation had originally been planned to start with program management and I got the impression that nothing was done to refocus the work on fundraising other than tell them to start using Salesforce. That first week in December, that org's fundraising team was using Salesforce but found themselves entirely unable to report on simple things like "How is the Giving Tuesday campaign going?" And from what I could tell, the main obstacle wasn't about not understanding Salesforce reporting. It was fields that weren't accessible, data that wasn't available, and the like. What I realized is that the person telling the fundraising team to use Salesforce is unaware of the distinction between product and platform. He seems to have thought that since they "had" NPSP they could just "start using it." But he'd done nothing to set up the instance to use NPSP features. That is not the way things work!  And just to be 100% clear, this story would be equally true if their org was on Nonprofit Cloud (NPC, currently named "Agentforce 360 for Nonprofits"). Neither "works" from the moment you "turn it on." They require extensive configuration and customization. The folks from this org described being on calls where they asked for, for example, a Gifts This Year rollup. The guy would quickly "do something" then tell them to refresh their page and there it was. I can't be sure, of course, but it sounds to me like in the moment he was simply adding fields to the page layout (or fixing field level security) that should have been there in the first place. They described this happening repeatedly. Basically Nothing Is Preinstalled I've pointed this out before so I'm just going to quote myself: You don't get to convert a trial org into your real instance. You can get a trial and play with it, but when you get your real instance it will be essentially a clean org, perhaps with NPSP installed, but only the package, none of the extras that were part of the trial, including record types, sales processes, page layouts, metadata records for NPSP features (like reciprocal relationships settings), and more. (This is, again, exactly how it works with NPC as well. ) The upshot is that even if you are implementing the most basic possible use case for Salesforce in the nonprofit context—which is to say "a simple use of NPSP/NPC to track donors and donations"—it will not work for users "out of the box." The page layouts will not show things like donation rollups for Total Gifts This Year or Last Year. Users won't, in fact, have permissions to view those fields at all, neither on page layouts, nor reports. When users try to enter a new donation, they won't find an opportunity record type whose page layout has the fields they need, whose stages match the stages fundraisers use, or that can record multiple payments on a single pledge. Users won't be able to send email acknowledgements for gifts. Most of this stuff exists in the back end, it's just not enabled. From the user perspective, they're going to decide that Salesforce is either broken or useless, or at the very least very confusing, and walk away if they can. Sadly, our beleagered friends from NPSP Day Philly don't have the option of walking away. Their contract for Blackbaud/Raiser's Edge expired at the end of 2025. So they had no choice but start doing their work in Salesforce. That means they're coming up with all manner of workarounds to just record something, anything. Who knows which opportunity stages they're setting gifts to? Who knows if they're entering donors in consistent ways? I get anxiety just thinking about it. (And they're not my clients.) The Trials are Products (ish) If you spin up a new trial org (for either NPC or NPSP ), I would say that's a product. What you get with a trial is a fully-configured Salesforce org [presumably] meant to show off how you would/could do fundraising as though Salesforce was a fundraising application, not an extensible platform. Fields are on the pages, record types are enabled, buttons and quick actions are in place, donation rollups calculate, etc... It's basically a turnkey fundraising tool. I would call that a product. [Side note: That first login for the first user is still gonna to be rough . All kinds of annoying pop-ups, all list views go to empty Recently Viewed, some objects have no list views set up at all, you're not immediately in the right app, etc... But plenty of products have less-than-ideal UX when you first use them.] However, since you can't use that trial for more than 30 days, it's not that relevant that the trial is a product . It's not a product you can buy! When you get your real instance, you merely have the platform (essentially Sales Cloud) with a bunch more metadata sitting in the back end. You have to start customizing to even get to the point of having what you experienced in the trial org. I don't think enough people understand this distinction , particularly because this isn't how it used to be. Until a few years ago the process for getting your Power of Us donation was that you created a trial org, put in your Power of Us application, and when that was approved your trial org converted into a full Enterprise Edition. In that world, nonprofits all started with the same product. That gave us a common language and common experience. Moving to Platform But as soon as we customize our Salesforce instance to do more things than fundraising, or to do fundraising in different ways, or to add features to our particular type of fundraising, or to not do fundraising at all but still use the Household Account Model, we move from the world of product into the world of platform. And, frankly, that's where all the power is. NPSP or Agentforce 360 for Nonprofits are just two offerings in the world of nonprofit fundraising software. There are others, including Raiser's Edge. If you lay those three next to each other as products , you have to make a selection for your organization based on features and price. ( What else is there? ) Raiser's Edge might win in that head-to-head. ( Might. ) But what I think makes Salesforce a better choice than Raiser's Edge (for those organizations that have made an informed decision) is that Salesforce is a more extensible platform. If there's a feature of Raiser's Edge that you love that doesn't exist in NPC/NPSP, all you have to do is add it from the AppExchange or build it custom. On the other hand, if you want to add your program management database into Raiser's Edge, you really can't.

Here's an interesting challenge. Modern Classrooms Project, who runs a program for teachers, wanted to be able to show, on the account page, counts of various program metrics. For each of those metrics, they also wanted to make it easy for users to see which records went into those counts. Taken on their own, either request seems pretty easy. If you want a count (such as enrolled participants from this school) you can make a rollup summary field, either standard or using DLRS . And if you want to see the data that goes into that count, you run a report. [In theory, a related list could also fill this need. But if we're talking about having filters on the count or different counts with different filters, having filtered related lists for each scenario will get out of hand. Even for only one count, a filtered related list isn't going to be very functional and probably isn't a good use of screen real estate. And finally, assuming a lot of records meet the filter, it's never going to be as convenient to view those in a related list as it would be in a report.] But together these two solutions don't make for a good user experience. If we show the count on the page, users know the total. But it's not that easy for them to figure out which report they would run to replicate that total. And even if they know the report's name (perhaps we put it in the help bubble), it would be several clicks for them to actually run that report. Idea! 💡 But we can solve this with two fields: A rollup summary and a formula field. Only the second field, the formula, is going to be on the page layout. The rollup summary field is a helper that stays in the shadows. The Rollup Summary Fill the data in this field however you want. If a standard rollup summary field can do for you, great! But if you need relative date filters or other special powers, fill it with DLRS or even a flow. There's no special magic here, just get the metric you need populated into this field. While I'm at it, let me make a plea for documenting the heck out of this field! If it's a DLRS rollup, my naming convention is to start the API name with "DLRS_". And if the field won't be on page layouts, as these won't be, I also leave "DLRS_" in the field label. Note in the description, "Filled by DLRS," particularly since being in a DLRS doesn't result in an entry in Where is this used? And in this case, I would also recommend noting that it's a helper field for the formula, etc, etc. The Formula is the Magic Truly, the magic in my solution comes from the formula field. This is the field you're going to put on page layouts for users. It's going to look like your basic rollup summary field. It's going to show a number. But it's going to actually be a hyperlink. (So I guess it doesn't quite look like a basic number field, since it shows in blue.) The formula for this field is: HYPERLINK( "/lightning/r/Report/ Id_of_your_report /view" & "?fv1=" & Id, TEXT( API_of_your_helper_field ) ) It's outside the scope of today's blog to go deeply into how that formula is built. But a quick overview: It returns a hyperlink, so it will be clickable. In this case it's a hyperlink to a particular report. The two bold blue bits are simple enough: the Id of the report you are redirecting users to and the rollup summary to show the number as what this field displays. The bold middle line is where the report is getting the Id of the record on which we're displaying this formula put into a filter that's waiting for it. (See this Help article .) That's it! Now you can put the fields somewhere on the page and you get a result like this: Not just numbers, but clickable links to reports about each of those numbers!