It's kind of a long time since I wrote about documentation. But that doesn't mean I've cooled on its importance. (And my best advice is still just start writing!) Recently I've been thinking about ways to put documentation right where Future You is going to find it when you need it. I think of this kind of documentation more as "bread crumbs" than as traditional technical or user-focused capital D documentation. Without any plans to be comprehensive, here is my list of places to drop your crumbs. If you've got other ideas, please let me know! Description Fields This is the simplest and most obvious place. Salesforce has literally given us a spot nearly everywhere in the platform to leave notes for future builders. Make use of those Description fields! My personal rubric is that these descriptions should be written for a competent Future You or your successor. That is why, in describing this field, I assumed that any admin looking at this field in the future is going to know what DLRS is. Or if they don't know what it is, they should know that it's important for their understanding and how to access resources to learn about it (like its documentation site). If the admin looking at that description doesn't have that level of competency, they should not be an admin and should not be able to see that description. I am not going to write all descriptions "for a five year old." They are technical documentation to help technical users. (That's why they are different than Help Text.) We don't need to get silly here. If a field is totally obvious or the description would be duplicative of the help text, I'm fine with leaving it blank. For example, if you have a formula field on Contact called Age, I don't think it needs a description. (It probably doesn't need help text either.) I'm probably going to catch some flack now from people that want me to suggest that we should now always be filling Description fields because "that's what AI agents are going to look at to understand our orgs." Without going too far down that rabbit hole, I have two responses to that: Even AI boosters often compare AI to a clueless interns. See my comments, above, about writing descriptions for competent future admins. The AI agent can take in all the metadata at once (Contact field named Age. Type = Formula. Returns a zero decimal number. Formula is FLOOR(TODAY() - Birthdate) / 365.25) so it should be able to make an inference from that. I know AI does not gain common sense the way humans do, but until it has at least the basics to figure out a field based on characteristics of the field itself, it's not going to be capable enough for my needs. So why should I put extra work into catering to that level of [in]competency? README Components or Screens Some readers of a certain age may remember README documents from installing software on their computers. Those probably were read about as frequently as the user manual. But the idea made a lot of sense. Even if you were handed a single floppy disk or downloaded a folder they are a way to include some notes, hints, documentation right where the audience will find it. So why not do the same in Flow? Sure, every flow has a description and every component does as well. But sometimes, particularly on a complicated flow canvass, you might want even more space. Or you might want to way to call attention because the flow description is not going to be open all the time. So I've made README components on flows. This flow, for example, is a mess: That Get Records that's disconnected in the upper left is just a way to call a viewer's attention to a place where I'm going to put notes. (I could have used any other element, but I thought pink draws the eye.) READMEs are easiest on screen flows because you can use a screen component with a Display Text element to write to your heart's content. And it's even easier if you aren't using auto-layout because you can just stick that screen near the Start element without actually connecting it in the flow. In auto-layout this kind of addition will feel a bit more hacky, but I still think it makes sense sometimes. One extra component that does little or nothing, like an assignment at the start of the flow, is not going to significantly impact performance. But the notes might significantly help you out next time you open the flow. Hidden Sections Let me start by veering a bit off of Salesforce. On every single Form Assembly form I put a hidden section at the top, like this: What goes in there can vary widely. Notes about what this form is used for and how. Notes about how to test the form. A reminder of how people will get to the form. If this is a form that either redirects to a second form or is the second (or more) in a sequence of interlinking forms, a note about that is critical. I like to give myself a link that URL-prefills with a test record, similar to what you can see above, or fills some required fields so I can save myself time when testing. Plus I use this section to hold any fields that will be hidden and help power the form itself. Notice that I clearly mark that the section is hidden, includes notes, and holds prefill fields. I don't do this as often In the Salesforce context because Description fields can often fit the need. And I already talked about READMEs in flows. But if want to leave a note that you'll see when building or modifying a particular screen, you could use this same idea. Just set a Display Text component to conditionally display with some criteria that will be impossible for users to encounter. (Like the screen flow was launched with no value in recordId, the field that lets it know what record it's running on.) Then you can write all you might need. In a Validation Rule [This is the one that I really hope is going to blow your mind.] More than two years ago I wrote about using a before save flow with a custom error component to replace validation rules. At the time I said that I was likely to stick with validation rules because they're simple to update and can be found right in the Object Manager. I still feel this way. But, knowing that I can do the flow method means that if I find myself with a particularly complicated validation situation I have another tool available. And once there is a second place my validations could hide, I need to make sure I remember that. So made a validation rule: Now every time I go to Opportunities in the object manager for this client I'm reminded that validations are in Flow. No guessing. No "I vaguely remember..." Just easy breadcrumbs for Future Me to find his way.

Last post I wrote about the various ways you can require a field. I want to shout out my readers because y'all are a smart bunch! I got several comments about places I'd forgotten, so I figured I needed to do a follow-up post to bring things all into the same place. 1.1. Also on the Page: Dynamic Forms In the last post I started with requiring fields on the page layout editor. In my mind, I think, this was supposed to encompass any time you are building a "page" or "form" within Salesforce. The places where you can click the Require box. But I think that the way I wrote it implied that I was only talking about the Classic page layout editor. So my first shout-out is to Stacy Irwin for calling attention to making fields required on a Dynamic Form. As Stacy notes, "Data imports and the classic interface won't enforce it." Think about that for a moment. Data imports not enforcing I had mentioned. But if you have any potential use case where someone could switch to Classic, then your requirement on a Dynamic Form will not apply, only the state of that field on the page layout editor. If you've heard me talk about Dynamic Forms before—it's an aside moment in many of my presentations—you might also realize that field editability and/or requiredness on list views is also controlled by the page layout editor. That may change someday, but for now, you have to keep the page layout in mind in addition to the Lightning record page for exactly this reason. 1.2. Not A Page But Still A "Page": Screen Flows Heath Parks was actually first to call out one of my omissions when he commented on my LinkedIn post to mention requiring fields in screen flows. A great point! Of course we sometimes require fields in screen flows. And it's worth calling attention to the idea that you might require different fields in the screen flow than you might on the page layout. But Heath's larger point was that you can use screen flows to require different fields at different times than you might in the general user interface. He said, "I have found this useful in cases where you now have guided screen flow to do an Intake and now some fields that were optional on an object are now required, so this way all new records get the required information and any legacy records we can still edit, etc as needed." In oter words, a screen flow is replacing the New button, so any time a user is creating a new record they're going to fill out the important fields. But the Edit button on existing records does not force users to fill in details they might not have if they're making a small edit to an old record. Keep Your Data Clean Lastly I'm going to reiterate something that I wrote last time in a parenthetical and now I think I should have highlighted more: Just because you require a field, that does not ensure clean data! Users are sneaky. They'll just fill in garbage values to get past a required field if they have to. This is particularly easy with text fields where they can just mash the keyboard. But they'll do it for numbers, emails, dates, or even picklists. I don't think there is any technical fix for this. The solution is social and has two main components: Take your users' feedback and build it into the system. Maybe a field doesn't need to be required at all. Or maybe it should only be required at a particular stage. Users are the ones that understand this, often better than admins. Teach users the value of clean data. Help them understand the reports and management functions that these required fields are driving. My gratitude to all of you that read this blog carefully enough to spot my omissions and generously enough to point them out to me. Plus extra thanks that you all do it in positive ways!

"Requiring" a field can mean a whole bunch of different things and I see confusion from admins all the time. There are [at least] four ways to require fields. Let's look at them in the order I prefer to think about them: 1. On the Page Layout The easiest and most useful place to require a field is on the page layout. Here, all you have to do is check a box and any user that creates a new record or edits an existing one will have to put a value in the field before they can save. We're all familiar with the red asterisk that designates a required question on a survey or field on a form. If you want to be certain your users will enter a value, this is the place to require your field. Required fields are a powerful way to keep your data complete. [Of course, requiring a field doesn't ensure clean data. If users want to save a record, they'll enter a garbage value just to get past a field requirement...] Obviously you'll have to put some thought into which fields are required on the page layout (or on which page layouts). But I don't think I need to spill a lot of ink about how to think about this. Remember, though, that a requirement on the page layout is not imposed on record creates or edits that happen through imports and integrations. This is important to keep in mind. If an integration leaves a field blank that's required on the page layout, the next user to edit this record will be forced to fill the field. Depending on your use case this could be quite an annoyance or it could be a useful part of how the work gets done. 2. At the Database Level The most fundamental place that you can make a field required is to set that requirement at the level of the field definition in the database. But generally speaking, you should shy away from requiring fields this way. I often get confused clients that have created a new field and now their users can't save records. Or they are editing the page layout and can't uncheck the Required box for that field. That's because they have required the field with that innocent-looking checkbox on the field definition and they didn't the implications. Just as the field text in the wizard implies, if this box is checked then every record must have a value in this field. Records that existed before you created the field will no longer be able to be edited without putting a value here. New records will always have to be created with a value in this field. When you put this field on a page layout it will always show as a required field. [This implies that you must put the field on page layouts as well, but there is no technical requirement that forces you to do this. Of course, if the field isn't shown or if users don't have access to the field, they won't be able to create records, since filling the field is a requirement.] Requiring a field at the database level is very powerful. Also risky. And sometimes confusing. I recommend that you rarely require fields using this checkbox. Not never, but it should only be done with careful consideration. If you are creating a net new object it's OK to require fields this way. But you should still only do it for fields that you truly intend will always be required for the object you are creating. Remember: a field required at the database level is required in all cases. That means imports, integrations, API calls, or other non-user interface creates and edits are still subject to the requirement for this field. If you're creating a new field on an object that already exists and is in use, you need to have a plan for how all the existing records are going to get a value in this new field. If you don't fill it every user that interacts with those records is going to be unable to save. And if they interact secondarily—like by kicking off a flow, or changing a rollup summary value—then there is going to be an error because the related record can't save. This could be an error that stops the user from doing their work. Or it could be errors that you have to deal with as the admin, like form submissions failing or asynchronous rollups being unable to calculate. Let's say you are creating an Exam object. I think it's a safe assumption that the data would be meaningless without a Date of Test field. So go ahead and require that at the database level. And, of course, who took the test is going to be pretty important, so you'll need a Student field, and that can be required. But probably the Score field should not be required at the database level. Why not? I often have cases where we want to enter exam records without scores to know that students took the test, but the score information isn't ready right away. If you want to do this then you can't require Score. If Score is required at the database level it will be impossible to enter any exam records in any way until you have the results. But an exam with a student and a date is still useful information because you can run a report of which students did not take the exam yet, and thus need a make-up date. As far as that Student field, we know that fields that relate one record to come in two types: lookup and master-detail. One main difference between the two types is that master-detail fields are always required at the database level. It actually says this in the field type description. Master-detail fields define a "parent-child" relationship and I think that's a useful metaphor. It is not possible for a child to exist without a parent or (two). Lookup fields are not "parent-child," they're a little looser and, therefore, don't have to be required at the database level. They come with choices about how the database should respond to deletion of the record being looked-up to. You could make a lookup required and then choose the "Delete this record also" option and you now have as tight a relationship as exists for a master-detail field. But the flip side is that you could not set a lookup to be required and then you could allow deletion of the related record to just clear the lookup field. Going back to our Exam object example, either of these field types is equally good for the Student field. If you select Lookup, setting it required at the database level is still probably valuable: I can't see how the exam record would be useful if you didn't know who took it because that student has been deleted from Salesforce! By the way: A field required at the database level will always be have a greyed out check in the Edit column when you're looking at that field in the object settings for profiles and permission sets, even if this profile/permset has no access to the object. Here's the logic: If this profile/permset were to grant create or edit access to that object then the user must be able to edit that field, since the field is required in all cases. Imagine if you tried to grant someone Create/Edit on Account but tried to keep them from editing the Name field. How would that work? Of course, if the profile/permission set isn't granting object-level Create or Edit then no fields are editable. But if it grants Create or Edit, edit for this field has to come along for the ride. 3. Validation Rules Requiring a field with a validation rule will (unless you specify otherwise) apply equally to the user interface and to integrations and imports. So perhaps you have reasons not to set a field required at the database level. But you are going to require the field on the page layout and you also want to require it on all imports. A validation rule is a great tool for this. The real beauty of validation rules is that they can be much more flexible than just "fill this field." You can write a validation that requires one field if another is filled. Or, conversely, requires that one be blank unless another is filled. I regularly do this kind of thing with the Payment Date field on NPSP's Payments object. I want that field blank if the payment isn't paid. But if it is, I want to ensure I get the date. 4. Before Save Flow with Custom Error Message (This should maybe only be numbered 3.5.) A relatively recent feature that works similarly to validation rules is a before save flow with a custom error message. Fundamentally, I'd call these a fancy and more-modern type of validation rules, in that they can prevent saving if a record doesn't meet your criteria and can display a message to the user so they can fix the data. What makes before save flows even better than validation rules is that you have all the power of Flow to go into checking if the data meets your requirements. A validation rule is just a formula and, therefore, is limited to formula functions and spanning lookup relationships to see related data. In a before save flow, on the other hand, you can look up other records (such as child records), run calculations or comparisons, or do just about anything else you can imagine before showing the user a message. There's a huge amount of power here!

Recently a client needed to take the options selected in a multiselect picklist and output them as a list for use in an Awesome Table that's on their website. The Awesome Table takes a list of members and their interests makes it sort- and filterable. So in our implementation of Salesforce we needed to have a multiselect picklist to capture those member interests. And then we needed a way to output that picklist for use in updating the Awesome Table every so often. Sounds simple. At first. Ah, multiselect picklists. You have to both love and hate them. Such a mess for reporting. But so required for many a real life situation. Sometimes we have no option but to slog our way through. First Problem The first challenge with multiselect picklists is that the order of values is not fixed. If you select a value at the bottom of the list, then one from the top, they'll stay in the order you added them. They won't be in the order of the picklist value options. Same Picklist. Different Order of Selected Options. The vast majority of the time, that's fine. But when you're trying to look at a report it becomes a lot harder to tell when people have a value in common. And that out-of-order possibility, as you might guess, was going to wreak havoc when used to sort and filter on an Awesome Table. So I had to come up with a way to ensure that my values were displayed in the same order regardless of the order they were added. Formula One It's actually not that hard to translate a multiselect picklist into text that will ensure the order. You just write a formula that concatenates a series of IFs that either show a bit of text if a particular value is present (is "included") or nothing if it's not: IF( INCLUDES( yourfield__c , "Option 1"), "Option 1; ", "") & IF( INCLUDES( yourfield__c , "Option 2"), "Option 2; ", "") & IF( INCLUDES( yourfield__c , "Option 2"), "Option 3; ", "") If all three options are selected, the output is: Option 1; Option 2; Option 3; Fine in many applications. But that semicolon and space at the end (red, bold, and underlined for emphasis) is annoying. Plus Awesome Table needed things to be comma separated, not semicolons. Obviously I could easily swap in commas instead of semicolons in that formula. But there would still be problemmatic characters at the end. Making It Worse Thank you to the amazing community! I asked if a formula was even going to be able to do this and naturally SteveMo was quick to reply, with credit to Deepak Anand for teaching him this trick. To get rid of that trailing seperator we are going to first make things worse, then wrap the whole thing in a SUBSTITUTE function to fix it. In step 1 of the rewrite we actually add more characters to the end of our formula output: + 'MORE STUFF' Our full formula is now: IF( INCLUDES( yourfield__c , "Option 1"), "Option 1, ", "") & IF( INCLUDES( yourfield__c , "Option 2"), "Option 2, ", "") & IF( INCLUDES( yourfield__c , "Option 2"), "Option 3, ", "") + 'MORE STUFF' If all three options are selected, the output will be: Option 1, Option 2, Option 3, MORE STUFF If just one: Option 1, MORE STUFF Etcetera... So far we're actually getting farther from our desired state. (But since I replaced semicolons with commas, at least we have no more semicolons.) Then Better Now we wrap the whole enchilada in a SUBSTITUTE function (the bold first and last lines): SUBSTITUTE( IF( INCLUDES( yourfield__c , "Option 1"), "Option 1, ", "") & IF( INCLUDES( yourfield__c , "Option 2"), "Option 2, ", "") & IF( INCLUDES( yourfield__c , "Option 2"), "Option 3, ", "") + 'MORE STUFF' , ', MORE STUFF', NULL) This means, "If you find ', MORE STUFF', swap in nothing." So we end up with: Option 1, Option 2, Option 3 Et voilá! The "MORE STUFF" is just a marker for what you're going to get rid of. It's always going to be there at the end. And preceding it will always be your separator, regardless of which value was the last used. So the SUBSTITUTE function lops off the appropriate last bit. Here's how it looks in real life: Doubling Down to Hurt My Brain There are actually five different multiselect picklists for volunteer interests in this client org, divided into categories. So we have one of these SUBSTITUTE formulas for each category. Here's one, for example: And then we have one that puts them together, shows category names and then their values inside parentheses, and does the substitution again! So the formula output with all values in all five picklists selected looks like this: My head hurts just thinking about how I made this in the first place.

Did you know you can see email message list views from an Email Messages tab? You can't get to it from the app launcher, so I wouldn't call it "standard." But you also don't (can't) build it, so I wouldn't call it custom. "Hidden," I think is the right word. Swap in your My Domain to this URL: https://yourdomain.lightning.force.com/lightning/o/EmailMessage/list Bam! Now you've got a quick and easy way to watch for those automated emails sent from flows. Or a quick place to see what went (or didn't go) in the last hour. Or all sorts of other useful uses! It works pretty much like any other tab, meaning you can create your own list views, change filters or displayed columns, etc. It's just weird that you can't get to it in the normal ways. And, of course, you can't really edit those email message records, since they've gone out the door already. But at least you can find them quickly. Make a Tab Based on a question from a reader, I'm adding a quick update to my original post: You can make a Web Tab to easily get back to email messages. Just go to Setup> User Interface> Tabs> Web Tabs and then work through the screens using the URL from above. You'll have a tab that looks like any other custom object tab and you can add it to your apps (or your personalized tab list) anywhere you need.

Salesforce is making things so hard! (Again.) This time I think it's relatively unintentional, but should have been eminently foreseeable. Based on a change introduced in the Summer '26 release it's now a major pain in the butt to verify an organization-wide email address. If you've tried it recently, you would have found that you set up the org-wide email address, the person with access to that in-box clicks on the link, they log in, but the address never shows up as Verified. Lather. Rinse. Repeat. Try as you might, it doesn't work. I only managed to get it to work by accident after about my third try, when I just asked the recipient to forward me the verification email. I clicked the link. I logged in. It was verified. Unfortunately that's "working as designed," according to this Knowledge article. With the most recent release the verification link must be clicked by the user that initiated the verification in the first place. This is a change in behavior. And while it's certainly possible that I missed the notice about it, this wasn't well publicized. (Maybe it's somewhere in the release notes, but I can't find it.) Honestly, even if Salesforce had shouted this from the rooftops, we were a little busy with other security-related changes and would have missed it. This was poorly conceived. And very poorly executed. What's Wrong It might not be that bad that the person that initiates the verification for a new organization-wide email address must also be the person that clicks on the verification email (because after clicking, they must log in to the account that initiated the verification). But this is a change from how it used to work and it's basically secret lore. When the admin initiates the verification there is no instruction of any sort that the verification must be completed by that admin (rather than the recipient). Not on initial creation nor when waiting for it to verify. And when the verification email arrives to the in-box there is still no instruction that the link should be clicked by the admin that initiated the verification. There's not even any instruction that you'll have to log in after clicking. (In the past all you had to do was click; you did not have to log in after clicking.) After you click the link and are taken to the login screen, it gives no indication that the verification will fail if you aren't logging in as the user that initiated the verification. Come on, Salesforce, at least give us a fighting chance at figuring this out! Workarounds Can we get this to work? Yes. But it takes a level of coordination between admin and holder of email in-box that's a higher bar than usual. And if you don't even know you need to do it—I feel the need to remind you once again that it didn’t work this way a month ago!—it's an extremely confusing change of behavior and is guaranteed to cause pain and suffering. Think about it: how often is the admin creating an organization-wide email address going to be the one that has access to the email box in question? I would argue, "Not very often." If the admin is part of the program team (or sales operations, or any of a dozen other kinds of departments that might house Salesforce admins other than IT) they probably don't have any control over the email server beyond their own email address. Even if the Salesforce admin is part of the IT department that controls the email server settings, it’s pretty likely that the email being set up as organization-wide will not be an in-box the admin uses. (That's kinda' the point, in fact, of organization-wide email addresses. They're meant to either allow us to set up Salesforce to send as a particular person other than ourselves or as a shared address such as programs@ or info@.) If the admin is part of the shared address's team they might have access to that shared email box, but my hunch is that even this is generally infrequent. And if they're on a different team they definitely won't have access. Not to mention that if the admin is a consultant they're not even in the email system of their client in the first place. Setting up org-wide email addresses is usually part of initial implementation, so it's likely being done by a consultant… So if the person starting the verification can't act directly as the person receiving it, they have to let that recipient know what to do. But since Salesforce hasn't provided instructions at any point in the process, that's not very likely to happen. Work Together in Realtime If you have an existing relationship with the person that will receive the verification email, you can ask them to forward you that email. Obviously it's going to be best to ask for that in advance. And they need to know what you're talking about and what to look for as far as email they'll be forwarding to you. (And possibly why.) I actually think your best bet is to set up that org-wide email address cooperatively in realtime. Get on a Zoom together. Have the recipient log into the mailbox in question. Then initiate the verification. Ask them to open the email, NOT click on the link, and copy/paste the link into the chat window. You can then click the link and log in right away. It may take a moment to coordinate when to get onto a call together but it will probably save time overall!

I have to say it: I'm a little disappointed in us, as a community. Myself included. We've let the political winds of the country push us and we seem to have lost our focus on diversity, equity, and inclusion. I'm pretty ashamed about it. I think we can—and should!—do better. We used to. Not that long ago, if you were browsing the Trailblazer Community, or on Ohana Slack, or attending one or the other event, there would be a better-than-average amount of discussion about increasing diversity. From talk of how to increase representation of women in tech, community-presented sessions at Dreamins and Dreamforce about allyship, the formation of WITness Success and Dreamin' in Color, public celebration of employee resource groups from BOLDforce to Outforce, to promotion of the issue in official communication like the Salesforce Admins blog and podcast, it was possible to argue that the Salesforce community was more focused on needed change than many sectors of society, an especially welcome situation in business and tech. Were we groundbreaking revolutionaries? No. Were we necessarily even moving the needle? Also, unfortunately, no. Most of the time most of us were just going along doing our jobs, building and maintaining technology systems for businesses. Fundamentally, we were (we are) cogs in a capitalist system doing massive harm to people and planet. I know that. But it's possible to make positive change within the system so some peoples' lives are better even if all isn't perfect. I believe that talking about DEI at all is an important way to begin change. The fact that we talked about the need for change opened up room for change in small and larger ways. I remember being so pleasantly surprised to see packed sessiosn at my first Dreamforce about women being underrepresented in tech. On the one hand, the content was extremely basic and "old news" if you'd been paying any attention to women's equality issues. But it was clear to me that for hundreds of women in those sessions it was a revelation to even learn how underrepresented women are in the tech sector. The women exiting that session didn't suddenly reach pay equity with their male peers. But some of them probably started asking some pointed questions. I remember Marc Benioff talking in the keynote (at probably that same Dreamforce) about how the company had done a huge HR audit to determine if women were being underpaid relative to men in similar roles because Leyla Seka raised the issue. Surprise! They were. So (he claimed), they went about fixing it. And then the next year they found the problem had returned, whether due to bias at hiring and promotion time or due to employees gained by acquisitions. So he'd realized that they would probably have to go through the exercise every single year. At the time, he seemed committed to the kind of work it would take to try to erase the gender pay gap at Salesforce. Those were some of my earliest introductions to the Salesforce world. Later there was a community sprint group thinking about how to increase representation at events. And there were initiatives to support women- and black-owned businesses. And there were Dreamin' event speaker committees talking about first round blind session submission ratings and publicly talking about striving for diversity on the stages. I just don't see those kinds of things happening nearly as much anymore. Not zero, but a whole lot less. On the big scale, Benioff has joined the rest of the billionaire class on the regressive and authoritarian side of a culture war. Big companies are facing pushback from MAGA claiming that DEI is some kind of conspiracy to undermine fundamental rights. (Rather than actually being a movement to protect those rights for everyone.) OK, so Salesforce as a company isn't going to be a leader in DEI. But where are the rest of us? Why have we let this anti-equality backlash from a minority of voters change our behavior? That's it. That's today's post. I don't have answers, just questions to raise. Let's recommit to doing better. I'll be around, both in the virtual spaces and at events. Tell me what you're doing to increase diversity, equity, and inclusion in the Salesforce (or wider) community. Let me know how I can help. Challenge me on what I should be doing differently.

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.