Search Results

With the move to the new Nonprofit Cloud (NPC) Salesforce has made a very intentional decision that they want to divide the market for nonprofits using Salesforce into two distinct segements: large organizations and everyone else. (Side note: when I say "nonprofits," I generally mean "nonprofits and educational institutions." But that's too long to write every time.) Large Organizations For large organizations, NPC and EdCloud might be a good solutions (or might be so someday ). I think I've been clear in my prior blog posts like The Emperor's New Clouds , Extension Objects: There's Nothing to Like , and others, that I don't think the new clouds are All That. But let me assume that Salesforce will manage to fix (or paper over) the problems that I've pointed out. Clearly they're making investments in roadmap for the new clouds. So let me give the benefit of the doubt that eventually the new products will be desirable for organizations planning to adopt Salesforce and that orgs already on Salesforce will eventually see features of the new clouds that are compelling enough for them to want to migrate. (Reminder: If you're currently on Salesforce but want to adopt the new clouds, this is a complete re-implementation .) But barring changes that I can't imagine (and nobody I've talked to can see), the new clouds will still only be appropriate for large nonprofits . When I say "large nonprofits" or "large organizations" I mean universities, national or international nonprofits, foundations, large museums, and the like; organizations that can support a team of multiple Salesforce professionals, including developers, plus probably have cash for a lot of partner/consultant support as well. I really mean large organizations . The data model, back end setup, and feature set of Nonprofit Cloud and Education Cloud are just too complicated for even medium-sized organization to work with. So I say that these clouds might be useful for larger organizations because they can use their greater resources to take advantage of the technology in ways that others can't and to build a lot of customizations, workarounds, tools, training, and documentation that make the extra complexity of the products bearable. And let me be transparent: I don't work with large organizations and I don't have a lot of experience with what kind of setups they have. So I am giving this analysis from an outsider perspective. Given that the large organizations have so many more resources than smaller ones, I think it's probably appropriate (to some extent) that they spend more money and effort on their Salesforce org. They have needs around scale and complexity that would always result in more expensive implementations. Plus, from my perspective, large organizations have (or should have ) the resources and expertise (or can hire/contract it) to caveat emptor. (That means "Buyer beware.") Everyone Else Then there is everyone else that might want to use Salesforce in a nonprofit context. This means small and medium nonprofits. This probably means you , dear reader, or the majority of your clients. I can't say this more strongly: The Nonprofit Success Pack (NPSP) is the right solution for you . (I suppose that comes with a small asterisk. If you're too small, Salesforce itself might not be right yet. Perhaps you should just stay on spreadsheets for a little longer. And there are plenty of organizations that need neither NPSP nor NPC because they should use plain Sales Cloud or Service Cloud or a completely custom other configuration. ) "We're going to become the Red Cross of [insert niche here]!" I know that medium sized nonprofits often think they're going to become large ones someday. Certainly that's the hope of many a founder and CEO/ED of these orgs. It feels like my duty to point out the improbability of this. And anyway, until you are large—really large!—NPC is not a good fit for you. Not today and not, in my estimation, for at least five years (and probably longer). So, yes, plan your system with the future in mind, design for scale, and leave room for growth. But build a system that works for your org as it is today. Don't saddle yourself with overbuilt and extra expensive. If you have a system that doesn't work for your org today you're going to struggle with adoption in the first place. The Nonprofit Success Pack (NPSP) works great. It's easy for users to understand, has many features you and your users will appreciate, and can handle quite a lot of volume. If you really truly do get large someday, such that either you're hitting the limits of what NPSP can handle at very large scale or else just that you have grown to the point that you think you meet the criteria I laid out, above, for using NPC, then and only then would it make sense to go with NPC. Choosing NPC while you are small or medium sized because you hear all the hype from Salesforce about the "innovation" and "exciting roadmap" is not going to serve you well. As I did last week , I'm going to reach for a vehicular analogy: Buying NPC today is like buying a school bus when you have your first child because you're planning to have lots of kids. You'll spend years driving an enormous vehicle that's practically empty. And by the time you've gotten to that giant brood, we'll probably all be wearing personal jetpacks anyway. (One can hope!)

I regularly hear people claim that NPSP is "on its way out," or "already dead," or "Salesforce is going to stop supporting it." None of those things are true. Could they become true soon, quickly, or without any notice? Yes, they could. But Salesforce could also decide at any moment to stop developing, kill, or completely change Nonprofit Cloud. Right now I don't think they are going to. But my point is that they could . Salesforce is a giant corporate capitalist enterprise. It fundamentally exists only to make money. If it isn't making money on nonprofits, or through the Industries model, or whatever, it will change what it is doing. And Salesforce is run by people, who can change their mind, or their business vision, or, for that matter, can change jobs. So if the people in leadership were to decide they didn't want to be in the nonprofit market at all, the company could exit it on a dime. If those people decided that the nonprofit price point should double, there is nothing tangible to stop that from happening. (And for the sake of future-proofing this article, I should probably also note that Salesforce could change the names of these and other products at any time.) Where was I...? Oh, right. Don't Listen to the Fear The Nonprofit Success Pack (NPSP) is not going anywhere. It's stable. It works very well for what it does. Thousands of organizations have it installed and use it every single day. Even if Salesforce wanted  to kill it quickly, they could not. There would be a very long tail of organizations still using the product. Besides, Salesforce has repeatedly said that they intend to continue to support NPSP. Sure, we could decide not to believe them. But so far I see no reason to be quite that cynical. Those of you who know me know that I'm plenty cynical. I'm just not that  cynical. I'm sticking, for now, with "Trust, but verify." Support for NPSP will continue, even though further development of it as a product will not. NPSP is Like Cars Let's face it, development of NPSP stopped a long time ago. Long before New Nonprofit Cloud was dreamed up. There haven't been significant new features in the core NPSP offering since Enhanced Recurring Donations, Customizable Rollups, and Engagement Plans and Levels, all of which are more than six years in the past. And some of those were just upgrades to existing functionality in the first place. But just because there hasn't been much development doesn't mean NPSP is somehow outdated. I would argue that development of NPSP slowed and basically stopped because it reached the point that it was meeting the truly common and shared needs of nonprofits. NPSP takes Salesforce, reconfigures the B2B data model to make it work for tracking individual constituents and their households ("B2C," in the lingo), gives us relationship tracking between people, relationships tracking to multiple organizations, and powerful flexible donation rollups. That's basically the common set of CRM needs for nonprofits. Everything else that Salesforce.org used to publish was for a subset of the market—for good reasons! The Program Management Module only works for the program model of certain kinds of organizations. Outbound Funds is great, but only if your organization needs to track...well...outbound funds. Etcetera. And I think this is OK. NPSP reached the point where it was doing what we needed and Salesforce.org realized that when they made new "products" it made sense for them to be optional add-ons, not additional bloat of the core product. Here's my analogy: What's fundamentally changed about cars in more than half a century? Basically they're boxes with four wheels that burn gas to move people around. We invented automatic gearboxes, seatbelts, brigher headlights, cruise control, fancy radar for lane keeping and collision avoidance, and backup cameras. But my great-great-grandparents would have no trouble recognizing today's cars and even taking them out for a spin. Even electric cars are just not that fundamentally different. [I can say this with confidence: I own one. It's great. But when you get down to it, it's just a car.] So I think the future for NPSP looks a lot like the last decade or so: It works great. It's stable. It runs on a state-of-the-art platform that you can customize to the nth degree. There are a zillion organizations (and people) using it. And there is an amazing community of practitioners that work with it and welcome new people to its use, teaching, coaching, and training them. I still think NPSP is the right choice for 95% of nonprofit organizations that are thinking about implementing Salesforce at this moment. And those that are already on NPSP should not be expecting to migrate off any time soon. On a Wild Ride Does any of this mean that the future for NPSP won't be a bit of a ride? No, of course not! Just as two years ago Salesforce pulled the rug out from under all of us by announcing that NPSP would be replaced with NPC, which would be an entirely new system and migration would require a complete org swap, there could be surprises in store for all of us. I'm just trying to remind you that this was always the case. This is where I believe in the power of the Salesforce Community, particularly the Nonprofit Community. We are scrappy, and determined, and smart. If NPSP stops looking viable, then we'll come up with alternatives, whether it's re-creating the core functions through a community-supported free alternative, or building tools, templates, and workbooks for migration. If we come up with some Must Have feature that NPSP lacks and Salesforce is never going to provide, we'll build it and find a way to release it through Open Source Commons, or UnofficialSF, or somewhere else.

If you've tried it at all, you've probably noticed that the Salesforce mobile app acts significantly differently than interacting with the platform through a browser. I have to admit that I've only used the mobile app infrequently and, as far as I can tell, few of my clients have used it at all. So I don't pay it much attention. There are some Salesforce admins out there, like Terry Cole , that have put a lot more thought into the mobile app and a lot more encouragement for their users to adopt it than I have. But recently I had a client, Carol, that adopted the mobile app for herself. The main thing she wanted to do was upload a photo someone had texted to her to that person's Salesforce record. Seems like it should be [relatively] easy, right? So Many Actions Have you ever been working in the page layout editor and wondered about all the actions that show up in the "Salesforce Mobile and Lightning Experience Actions" section? Half of those, I'm not even sure what they really do, or if they work. And others are irrelevant clutter in this context, such as Submit for Approval , when there is no approval process for the object I'm working on. Plus there are the redundant ones, like New Payment , that replicate the function you could just get using the New button on the Payments related list. You may have tested this and noticed that lots of these don't actually show up for users (or you) because they relate to features that aren't enabled, or the like. Well I don't know about you, but that kind of clutter drives me crazy. It becomes hard to ensure that I've ordered the buttons in a useful way, not to mention that I haven't left on one or more that will confuse people So the first thing I do when I'm editing a page layout is to remove everything but the handful I actually want to display to users. So here's the button setup for a custom object called Onboarding: I removed a whole bunch that never get used and I've ordered the remainder in a way that generally makes sense for users: Cancellation Checklist (This is a regularly used custom quick action that had been built before I worked with them.) Change Owner (Onboarding owners are the people in charge of the record.) Then we have three buttons that actually show together in the Activity feed, not the button bar: Email , New Task , and Log a Call Printable View is rarely used, so I put it toward the end of the list. Change Record Type probably shouldn't even be here, as this object has no record types. (Since it doesn't display, I've never noticed that I ought to remove it.) Clone might sometimes be useful. Edit is often needed and I usually put it first of second. (I'm just noticing that it's in the wrong place now! But I think users in this org tend to click on the pencil icons instead of the Edit button anyway.) Post doesn't show up with the other actions, it displays in the Chatter publisher. And finally we put Delete last on the list because it should be the least frequently used. (Often it will end up under a carat if there are a lot of buttons on the page.) Here's what those result in when you're actually on a page: Better for Users than Admins Quick side note here: The final button order looks pretty good for users . (Though, as noted, I think Edit should be third and I'll probably make that change when I finish writing this post.) But the order in the page layout editor as an admin is confusing, particularly due to those actions that don't display in the button bar (like Post) or, like Change Record Type, don't display at all because there are no record types. On my best days, I'll reorder everything so that those ones are grouped at the beginning or end, or take them out of the layout entirely to reduce clutter. But other times (like, apparently, in this case...), since I know which ones display in their own places, I just leave them where they fall. What can I say? Sometimes I'm lazy. 🤷🏻 No New Button on the Files Related List in Mobile What my user, Carol, found was that even though she has no trouble uploading files to Onboardings in a browser using the Add File button in the related list, she wasn't able to figure out how to do it on mobile. The related list looked like this: Notice that there's no New or Upload button. When she asked me about it, I was confused too. How I Solved It It turns out that this is one of those situations that cleaning up the clutter created its own problem! The Files button that you probably see all the time in the page layout editor but doesn't show up when you view the page is actually what enables mobile uploads! So I had to edit the onboarding page layout to have these options in the Salesforce Mobile and Lightning Experience Actions section: See how I've added File second in the list? Here's an Onboarding record in a browser now: File does not appear there. But if you pull up that same onboarding on your phone: File is right there after Cancellation Checklist. So now it's possible to attach a photo from your phone to an Onboarding record. What seems like "clutter" can sometimes serve a purpose.

If you're like me, you're probably drowning in all the announcements from Dreamforce 2024 about generative AI (genAI) features under the Einstein and Agentforce branding. And you're probably asking yourself, as I am: "How much is this stuff going to cost?" These genAI features are going to be far from free. You're going to need the right kind of licensing and you're going to consume credits. Licensing The picture on licensing cost is starting to come into focus. Any user that is going to actually use genAI will need to have a proper license. Using genAI means sending a prompt to a generative pretrained transformer (GPT) and getting back results in the form of text, created or rewritten. Users that aren't the requester or the direct recipient of the AI answer should not need an AI license. Licensing your users starts with two options: Einstein 1 Edition This is a rebranding of Unlimited Edition, with Einstein for Sales/Service bundled (see below), Data Cloud (presumably with more credits than the free allocation), and some other things. ( You might recall how I feel about UE. ) With nonprofit discount these licenses are $3,600/user/year (down from list price of $6,000). So to summarize, my understanding is that if you're on Einstein 1 Edition then you pay for genAI features for all users, whether they send prompts to EinsteinGPT or not. Einstein for Sales (or Einstein for Service) This is an add-on license (probably a Feature License) that can be assigned to a user to enable genAI tools. It's my understanding that you can buy these add-ons only for the users that need them , which will save a lot of money. You're not going to need GPT for every person in your org, since some people will not send prompts. Your AE will probably imply that you should get one for everyone, but you should not . ( Spoiler Alert: AEs are Salespeople. ) The Einstein for Sales/Service add-on is $900/user/year at list price. As of this writing, I have not yet seen a nonprofit discount price. Since Einstein 1 Edition for nonprofits, above, comes to 40% off list price, I expect the nonprofit discount for Einstein for Sales/Service will probably be similar (so perhaps $540/year). [PS - I don't think there's really a huge distinction between the Sales or Service versions, they're naming that's meant to parallel the licensing naming. ( Don't buy both  Sales and Service if you're a nonprofit!) ] Even if you economize as much as possible, it's looking like a minimum of more than $500/year to get AI features, for just a single user. Valid testing, let alone usage, is going to require at least the admin and one business user. That could become a significant additional annual cost to your "free" nonprofit software. By the way, with all the announcements leading up to and during Dreamforce, I'm writing this without a clear understanding of whether "Agentforce" replaces the "Einstein for" branding or if Agentforce represents something entirely new. GenAI Credits Once you've got the licensing in place, you're going to consume "credits." This is where I really can't help much with specifics. I'm not sure anyone can yet. First of all, I've asked around and have yet to understand which actions will actually consume a credit, or whether certain actions consume multiple credits at a time. If you read carefully in the nonprofit pricing guide PDF , you might have noticed that Nonprofit Cloud Einstein 1 Sales entitles you to "All features in Unlimited Edition plus Einstein for Sales (25K AI requests per user per month)..." I think that implies that 25K requests per month is also the allocation you'd get if you bought Einstein for Sales on its own. (But don't quote me on this.) Twenty five thousand AI requests per person per month sounds like it could be quite a lot. But is it? If the idea is to individually personalize fundraising emails to your entire list, that could soak them up pretty quickly if your list is large. It seems like it should cost a minimum of one credit per person on the list, since you would be asking EinsteinGPT to personalize to that potential donor. But at least you know exactly how many people are on your email list and how many email appeals you want to send. The other commonly-discussed use for GPT is for something like a customer service chatbot. A university might want to have a registrar's chatbot that can answer students' questions about course add/drop, or a comptroller's chatbot to help them make sure their student account is paid. Estimating credits for those use cases seems a lot less straightforward to me. I would assume a credit is consumed with each response in the chat. (Surely it's not just one credit per conversation.) Deploy that chatbot where a lot of people might use it (kinda' the point!) and you could start soaking up credits fast . We got at least one pricing clue in a September 12 press release from Salesforce. It's a rather long read for a press release, but at the very bottom you find, "Agentforce pricing starts at $2 per conversation; standard volume discounts apply." In some ways that generates more questions than it answers. Are "conversations" the same as the "requests" I was quoting numbers for above? Do you have to buy some bundle of conversations up front, or is it entirely based on usage? Does building and testing in a sandbox come free or still cost per conversations? What, if any, licensing is required to access Agentforce for Sales and Service? How will you know if you're going to get a huge bill? Plus doing a lot of this this might also require that you consume some (or many) Data Cloud credits at the same time...? Data Cloud Which reminds me: I've heard several references to possibly "requiring" Data Cloud in order to use Einstein genAI features. I have little to no understanding of what that actually means or whether you would need to have something beyond the free Data Cloud that every org is entitled to. I can see why this would be required if you wanted to combine your Salesforce data with data in other systems (email marketing, web click tracking) before you send it to EinsteinGPT. But I don't know if Data Cloud would somehow be required if you only want to use Salesforce data. If you have to purchase Data Cloud beyond the free allocation, my understanding is that it starts at $100,000/year! (Plus the cost of implementing, of course, which you're surely going to need a large consultancy for.) Nobody Knows 🤷🏻 Let me be fair to Salesforce here, though: I don't think they know how consumption-based pricing is going to work either. Their costs to provide these services to customers are consumption-based, because that's how cloud computing services are priced, whether genAI or elastic web storage. So they have to balance a massive uncertainty in how much their costs could balloon if people adopt these features. They're trying to offer the fancy new features that they think people want while figuring out the cost, pricing, and revenue models all at the same time. It certainly seems like the wave of the future for Salesforce costs will be more consumption-based and less fixed-price license based. But the actual outlines of that pricing are still pretty hazy.

I'll be presenting at Dreamforce in a couple of weeks, which I'm very excited about. [I hope I'll get to meet you there! If you're a reader, please say Hi. I'll even give you some stickers!] If you have never been to Dreamforce, it's quite...something. Over forty thousand of your closest friends, in packs of Trailblazer hoodies , taking over the streets of San Francisco . I should say it's probably not worth the cost for most people compared to going to Dreamin' events . (In fact, I should probably write a whole post about that!) But Dreamforce is something to see. I think everyone in the Salesforce ecosystem should experience the Mother of All Salesforce Events at least once. I mean, I got to see U2 at my first Dreamforce. It's not all conference rooms and PowerPoint. So if you're going to Dreamforce this year, or thinking about it for the future, here are my top tips for surviving and thriving. Comfortable Shoes 👟 I'm kidding here. Yes, you should wear comfortable shoes. You're going to spend all day on your feet. But this piece of advice has been given in a million blog posts, podcasts, and Trailblazer Community posts already. It was just a joke for me to throw it in. This post is not meant to be a rehash of what's been written before. Shorten Your Lanyard 🏷️ I've been on the record many times as a fan of name tags. And your Dreamforce badge is truly required to get into any space of the conference, so you're going to be wearing it all the time. Make your name visible by shortening the lanyard. I usually tie a small knot in the lanyard, which raises the badge closer to my chest than my stomach. If you're wearing a hoodie, you can put the lanyard around the hood, instead of just on your neck. If you have a collar, put it outside that. But I still think tying a knot is the best way to go. The benefit here is that even when you're sitting down, other people can see your name easily . Trust me—you'll appreciate it when you can remind yourself of the name you didn't quite catch over the noise. Skip the Marketing Sessions - And Too Many Are Marketing Sessions There's just no way around it, if a Salesforce employee is delivering the session, it's almost certainly going to be marketing. Lots of blah blah blah about the hot new thing and how it will change everything. (Last year and this year: Generative AI.) In my opinion, these are total wastes of time. This applies—perhaps especially applies —to the keynotes. (Yes, all the keynotes. Marc Benioff puts on a good show, but the main keynote is nothing more than an advertisement for new "features" that you probably won't ever use.) And anyway, you're going to hear about the main marketing push ad nauseum in a million other places. The main keynote doesn't have any other sessions happening at the same time, but there are plenty of other things to do with your time. As for the rest of the keynotes, I say look for sessions where you can learn real skills or meet real people instead. The other kinds of sessions I find tiresome are those where a partner presents with their customer about a big implementation. You can usually spot these with titles like "How the Food Relief Society Served Ten Million Meals" or "Quilts for Cats's Digital Transformation." The partner is there to market their company, sharing the stage with a customer that just spent tens or hundreds of thousands of dollars on a project. Salesforce gave the session a stage based on a recommendation by the sales team, with a marketing goal, not an educational one. With an implementation that big, the partner could never present all the nuances. The resulting presentation is too-simplistic and lacking in detail, leaving admins with little they can take back and use for themselves. But that isn't the goal of the session. The partner (and Salesforce) want executives at potential customers to be wowed so they'll do their own big implementation. As a hands-on-keyboard practitioner, I find these about as useful as the demos in the main keynote. Those demos are cool, but all I can think as I watch them is, "How many millions did this take to implement? And how much would it cost in annual licensing to support that org in real life?" Find the Right Sessions 🔍 So what sessions are worth adding to your agenda? Look for three categories: Anything presented by members of the community. These are going to be practical How To kinds of sessions, with real demos. (I'm biased, of course, since this covers my own session.) Community Cove events. These are also usually created/hosted by community members, though sometimes organized by Salesforce itself (members of the Trailblazer Community team). They're more informal, less "session" and more networking and discussion. Sessions run by Product Managers. This is the major exception to my rule, above, about sessions run by Salesforce employees. The product managers are actually building features, so these are chances to learn from the maker, see the roadmap for feature upgrades, and ask questions. Dreamforce has relatively few of these sessions, as they're more a focus at TDX. But read the Agenda Builder carefully and you'll find some. A special session worth mentioning here is True to the Core , which also features product managers, through it's actually facilitated/moderated by Parker Harris and senior technical leadership. This is the biggest, most public, place for admins to ask technical questions and advocate for feature improvements and interface upgrades. Network Network Network 🛜 The real reason to attend Dreamforce is to meet and hang out with people from the community. Sessions are interesting, of course, but the real value is in the people. When you're stuck on how to build something later these are the people you'll be able to ask. So introduce yourself to people in lines, sitting next to you in breakout rooms, and at meals. You never know when you'll run into someone you recognize from Ohana Slack or threads on the Trailblazer Community. Now you can pal around for a bit and turn a virtual contact into a real life friend. Pro tip for particularly for introverts: Find yourself a "Conference Buddy." The crowds are going to be overwhelming. But if you can find one person and connect with them for a bit, you'll be reenergized. Watch the online communities for events for newbies, including the Bacon Breakfast , the annual walk across the Golden Gate Bridge, and others. Definitely go to the First Timers meetup . These are great places to meet people who are also looking for a friend. Do the Quest—it’s fun! 🏅 Salesforce has significantly cut back on the massive swag load of previous years. But they still build in some kind of "quest" with good prizes like shirts, hoodies, and plushies. You usually have to attend a session or two of particular kinds, do a Trailhead module, and meet with some of the sponsors. It's not that hard. Check the Events app for the requirements and what the prizes are. There's usually also a paper handbook available at the information booths. Even if you have no interest in the prizes themselves, the quest can be fun. Plus it's something to do with people as you get to know each other. I have great memories from speed-running the TDX quest in 2023 with the Four M's (me, Monica, Misty, and Melissa). Besides the silliness of getting the prizes as quickly as possible, we had fun at the "escape room" and some of the other goofy games. Plus sometimes you might actually learn something, discover new products, features, or apps that you didn't know about, or even meet a product manager or find an exhibit booth you woud never have come across. Feed the Circular Economy ♺ Even if you don't care about the quest prizes and swag from exhibitors, you probably have someone in your life you can bring things back for. So take the good swag. Maybe you don't need yet another re-usable bag, or phone battery, or even hoodie. But your coworkers might appreciate them. (Or your family.) If you aren't into "stuff," that's fine. But you can be judicious. Only take the good stuff. Socks don't take up a lot of space. Plushies are bulky, but you'd be surprised how much people love them—even people that don't know the Salesforce characters. Stickers take no space at all. And yes, I'm aware of the environmental consequences and the waste swag can represent. But a few fewer stickers or pens taken from Dreamforce are not going to save the world. And if they'll bring joy to someone, that's got value. Your company sent you all the way to Dreamforce, you can share swag with coworkers as a sign of your appreciation. Or save the haul to bring with you to a user group or Dreamin' event. There are plenty of people that are involved in the ecosystem that don't make it to the big events or don't get their hands on a piece of swag they were hoping for. The more you give away, the more you build friendships in the ecosystem and spread the fun. Eat 🍴 For my last piece of advice, I'm turning to the practical: Don't forget to eat. Your Dreamforce registration comes with lunches. You need fuel to keep going. So make the time to eat. Bonus points if you manage to eat with one of your new friends. But even if you just need some time to sit quietly by yourself, get those healthy calories in when you can. And this applies doubly to dinners, in my experience. Lunch is at least served for everyone on the Dreamforce campus. (It might not be the perfect food you wanted, or the options might run out, but it's pretty good, relatively healthy, and will keep you going.) But dinner is on your own. You might manage to get food at one or another party, if you attend them. But I've learned not to count on that. Sometimes the food is insufficient. Or it's all gone by the time you arrive. Don't compound the exhaustion and the jet lag by also not having dinner. Grab a few people and head to a restaurant when the long day of sessions ends. Don't be shy: You can be certain that any group you announce a dinner plan to will have at least two or three people that want to eat with you! I also like to swing by Trader Joe's and grab some supplies to keep in my hotel room, both for breakfast and to keep some snacks with me during the day.

I've been working on an approval process for a client lately. I bet that's for a sentence you don't hear too often. But despite not having gotten updates in ages, they're a pretty cool feature. However, this post isn't actually going to be about approval processes. It's just that our story starts there. You see, I had a pretty simple requirement: Each step in the approval would move a record to the next stage. But we wanted to require certain fields be filled out at certain stages, as the record advances through the approvals. Page layout tricks wouldn't be the answer, since some approvers would only be approving, not editing the record. Time to write a validation rule . Only when I started testing, I found that records kept changing status and ignoring the validation. Thing I Learned: The workflow field updates that happen within an approval process do not fire validation rules. Fortunately, a few minutes' searching found me at this blog post , by Yumi Ibrahimzade, with a workaround. Build a before save Flow that checks if the record has certain conditions and then use a custom error component to show an error, similar to a validation rule. Problem solved! So interesting! I had never used the custom error component before. Idea! 💡 That got me thinking. This custom error on a before save Flow is pretty neat! Cooler than validation rules 😎 on a lot of levels. With branching logic and all the other powers of Flow, you could get super custom with what kind of validations you want. For example, you can make cross-object validations, that check the status of related records, not just fields on the record itself. Or you could validate based on non-record statuses, like day of the week, or user attributes, or even custom metadata records. Here's Yumi combining custom errors with Flow fault paths, so fault paths don't cause a Flow to fail silently for the user. I want to use these before save validation flows everywhere! Reality 🥱 But in truth, I'm sticking with validation rules. Sorry to be the splash of cold water. Validation rules have two major advantages: Transparency As much as the backwards formula logic of validation rules constantly trips me up (and it does!), they live right within the object manager. You can see all the validations for a particular object in one place. And you can also see what validation rules relate to a particular field right within that field's edit page. Ease of Maintenance I absolutely love Flow. But it takes more than a handful of clicks to make a new one. Or to open an existing one. Or even to activate and deactivate flows that are already built. And don't even get me started on the pile of Flow versions. So if you need a validation rule that can be built with a rule, it's going to be far faster to create a validation rule. Fewer clicks = happier admins. Let the Gears Turn ⚙️ But now that we both know about this, let it rattle around in your subconscious. Can you think of validations that would help keep your data clean that weren't suitable for validation rules?

You know what's also part of the design of your Salesforce pages? A whole lot of text. So far I've talked about color, eye movement, where you put fields, and more. But there is text around all those things, from field names/labels to the content of the fields themselves. Those are all part of the design! Field Labels When you create a new field, how much time do you really spend thinking about the label? If you're like me, it probably depends a lot on the context. Organizing a spreadsheet listing all the fields that will go into a new object I'm scoping out? I probably take some time to consider the labels in conjunction with each other. (And my stakeholders might have opinions as well.) But throwing together one or two fields as I'm making an automation or responding to a user request? Those field names happen more organically. Those two situations can result in very different sets of field names. This is my reminder to spare a thought for how field labels are going to interact with page design and other uses (like on a report). You get forty (40) characters in a field label. That's it—there are no workarounds. Keep this in mind, particularly when you're about to create a whole series of fields that you want to go together. If you have one that's going to be longer than the rest, best to abbreviate them all from the start than to realize the problem late in the game. If the labels in a section don't look like they go together that's going to be noticed at least subconsciously by your users and give just a little hitch of distaste. Nobody want's that! Balance Consider the screenshot below. It's not perfect—none of my designs are. But it works well enough. You've probably seen a phone/email section that looks a lot like this before. I'm quite happy with that section.. The phone fields on the left are grouped logically together. The email fields on the right parallel them. In the case of this org there is one more email field than phone field, so the right column is a little taller. But that imbalance makes immediate sense so I don't think it is a problem. Then the Career Fields of Interest section is balanced with just one field in each column. (Note that it somewhat violates a suggestion I make below. But I'm not perfectly consistent.) Then the Communication Preferences section has four checkboxes. They're all in a single column because even though it makes the overall page taller (more scrolling = bad), dividing them into two columns would make the logical grouping hard to figure out. And I expect people will collapse this section most of the time, so the height matters less. Help Text First of all, consider this my plea for including help text as frequently as possible as long as it's useful. Users really do appreciate it when it's there! This can take a moment extra each time you make a field—and particularly when you're making a bunch of fields at once—but it's worth your up-front seconds to save users a minute or more of confusion later. Let me also note the aesthetics here: If some fields have help bubbles and others don't it can make your page layout look uneven or unbalanced. We wouldn't want that! No, seriously. We don't want that. Notice the screenshot above, where two fields in Communication Preferences have help bubbles and two don't. That bothers me. I might need to to fix it right now. In a perfect world I would say that all fields in a section should either have help text or none should. But the world isn't perfect, so you'll have to weigh the small clutter or unbalance with the useability tradeoff of the guidance. Guidance Speaking of guidance, here's one of my favorite tricks: See how there are fields in this Phone Interview section that start with a 🗣️ emoji and then actually have the what the user should convey to the stakeholder? Without having to use a screen flow we've converted part of a record page into a script for a phone interview itself. How did we get these guidance sections onto the page? Simple! They're text formula fields. Not complicated formulas, either: This trick allows you to place text within the detail page layout instead of having to put it in a rich text component above or off to the side! 1 or 2 Column Sections Probably one of the things that drives me most nuts is when I see someone's page layout that has a long text field in a single column. It's just...wrong. It's one of the first things I clean up when I work with a new client. (If I can get agreement to change page layouts.) If you're going to make space for your users to fill in a longer narrative it should not be squished into a single column. It will be hard to read, wrap funny, and force users to scroll further to see things below that field. Put those fields into a one-column section—on their own if need be! If you create a one-column section and turn off display of that section's header it will act as though it's part of the section above it (even collapsing along with the collapse of that section). Look no further than the standard Description field on Account. Salesforce puts it into a two column section by default for a reason. And when you create a new long text field and have Salesforce auto-add it to a page layout, it goes into the bottom of the first one-column section, while most other fields go to the bottom left column of the topmost section. This different behavior exists for a reason! By the way, multi select picklists should get similar treatment. When there are multiple items selected, MSPs look like long text (separated by semi-colons). And in edit mode you're going to need room for both the choices and the selected choices. Look how squished an MSP looks when it's in a single column in edit mode: Isn't this better? Related List Details Here's another trick I like to use. It can be hard to glance at a related list and get all the information you might want about records there. So create a formula field on the child object that pulls together a few fields' worth of information and display that field as the prominent column in your related list. Now you probably don't even have to open the child records. Here are individual grades on a student's report card: The Detail column tells me what I need to know without having to add three columuns to the layout. Or you can put details into the name of a record using a before save flow every time the record is edited. These college applications' names tell most of the story. Design Is Not Just About Imagery and Color When you're adding text to your Salesforce pages, that's part of the design of the system, whether that text is a field label, the contents of a field, or the text within a help bubble.

How much thought do you spend on the order of buttons in your instance? So often I'll see a vastly different button order on pages for different objects and it makes me crazy! This post is my plea for you to give some thought to those humble, but oh-so-important  buttons.  Those buttons constitute a huge percentage of the things your colleagues are clicking on. So save them mental effort and save them clicks! By the way, in this post I'm going to refer to "buttons." But depending on the context in Salesforce these are sometimes called "actions" or "quick actions." The name isn't important. I'm talking about the things at the top right of the page that users can click to do things (and also the things at the top of the Chatter feed and the Activity Feed that users can click to do things). At the top of the page these always look like square buttons. In Chatter and Activities they can be tab-like, or button-like. Side note: I think it's very confusing for users that those buttons stack similar items (like Task actions) under carats. So I usually set my Activities component to "Use tabbed activity view," which goes back to the tab-like buttons that were the original design. Salesforce changed the default and all existing orgs to the new style about two years ago, so this is probably a losing battle I'm fighting. But if you have only three or four buttons, as I usually do, I think the tabs are less confusing than the dropdown carats. But for my purposes today these are all "buttons" in the sense of being places on the page that, when clicked, result in some UI action. Constant and Curated Order The order of your buttons should be pretty much the same across all your objects. Of course objects that have more or special buttons are going to mess with this principle. But for a moment let's speak only of objects with the bare minimum of standard buttons such as Edit, Printable View, Clone, and Delete. [Spoiler alert: I couldn't even bring myself to write this post with them out of the order I'm going to recommend.] Edit - This is the button I assume users will click most often. (Sure, they might double-click into fields directly, but some people are focused on buttons.) If it's the one that gets the most use, I strongly believe it ought to be first, which is to say "farthest to the left" (for left-to-right languages). Printable View  - I struggle even more with whether this one should stay on pages. I suspect it's very rarely used. The result can look terrible, yet it's so much better in a pinch than trying to print or screenshot the lightning page. If left on the page, I still downgrade it. In this grouping, it's second-to-last. Clone - To be honest, I often struggle with whether to leave this on the page or not. But it's super-useful at times. Among these four, if it's on the page, I figure it will get used. Delete - Clearly this is needed on the page (for those with delete permissions). But deleting data should be rare. Therefore I always put delete last in the lineup and even behind the carat to remove temptation. There are other standard buttons you may need to use more or less frequently, such as Submit for Approval, Change Owner, Change Record Type, etc, in which case you'll have to make some choices. Use these principles: Edit goes first. (Though see below when it comes to custom buttons.) Delete goes last. Others are in order of [likely] usage on the object. Keep things relatively consistent across objects. (So if you add Submit for Approval and Change Owner on two objects, maybe keep them in the same order in both cases.) Custom Buttons So far I've only mentioned standard buttons. But if you've seen a screenshot of one of my orgs you know that I use custom actions all the time , whether simple Quick Actions on an object or buttons that launch a screen flow. These start to complicate design choices. First of all, I hope you've noticed that I almost always put emoji on my buttons. [ It's just fun! 🤪 ] So they end up looking a little different than the text-only standard actions. The emojis kinda' kill consistency in that sense, but I'm not willing to give them up. (Boy do I wish I could add an emoji to Edit everywhere. Perhaps ✏️. ) Nine times out of ten custom buttons are going to be inconsistent because their labels are longer than the standard ones. (If you're making a custom button for your users, the chance of naming it something as concise as "Edit" or "Delete" is pretty low.) So custom buttons are going to be inconsistent anyway... But "Where to put them"? is the question. And I usually answer, "First." As in, "even before the Edit button." This one will vary with circumstance, but I generally figure that if we have need for a custom button, we probably want it to be more prominent than Edit. On the other hand, Edit is a small unobtrusive button, so if you want to keep it first, that's probably OK. Number Displayed The other consideration that goes with order of buttons is the question of how many will appear on the page, with the rest sitting under the carat. Don't just leave the Salesforce default here! Show four, five, even six buttons on the page if they're all going to be needed (and have short enough names to fit when screens are resized smaller). Or set the number lower if you would prefer to hide things (like Delete) under the dropdown. (But remember that some users will forget or never discover that there is anything under the carat, so be ready to train and remind.) [By the way: While you're here in the settings pane for the Highlights Panel, I suggest you always check Hide Follow/Unfollow button (desktop only). Unless you know for certain that your users follow records in Chatter, which I think is pretty rare, it's just clutter on the page.] Actions in the Feeds Let me remind you that everything I've written should apply equally to the buttons that appear in the Chatter Feed and the Activity Feed . In most cases there are far fewer buttons to consider here. But briefly: Chatter Feed - By default, Salesforce includes the Poll button. I strongly suspect nobody ever uses this. So remove it— everywhere . (By editing the Global Publisher Layout.) I think the only button you need for the Chatter feed is Post. Activity Feed - Here you are likely to have Log a Call, New Task, and Email, among others. (I usually don't use Events.) The first principle I try to use here is to move the more-used tool (email or task) leftmost. On Contact, for example, perhaps we expect to log a lot of calls. I'll put it on the left so it's the easiest to find. I also try to put the two (or more) task buttons in what I think of as chronological order. Log an Interaction (my renamed version of the standard Log a Call), used for a task that has already finished , goes to the left. New Task, an item for the future , goes on the right. Users might not pick up on this timeline ordering consciously, but I like to think it helps them make the otherwise-subtle distinction between the two buttons. How to Control Them But I guess I should briefly mention how to work with these. The first place to look is the Global Publisher Layout (Setup>User Interface>Global Actions>Publisher Layouts). This amounts to your org's global default setting for placement of actions that apply across objects. If the action layout is not overriden on an object page, what you've set here will control. So take this chance to put things in the default order you'd like. But each page layout can have its own settings if you have overriden the predefined actions. (By the way, don't be afraid to override the predefined actions! ) The order of buttons on both the page and in the feeds is controlled in the Salesforce Mobile and Lightning Experience Actions section of the page layout editor. This is where you'll change the order for a particular object and where you'll add object-specific actions, like the custom buttons we talked about above. (Of course, if you're not using classic page layouts and have switched to Dynamic Forms , then you'll control button order in the Lightning App Builder.) You Have the Power Now that you've got all the tools, go and apply you design sensibility to the order and placement of buttons and actions on your pages!

Here's an idea most people don't consider: Screen flows can be page layout elements. I'm not talking about the design of the screens in the flow. (Though clearly you should design them.) I'm talking about using screen flows as part of the way you design a record page. Whether you're using just standard flow components or add-ons from UnofficialSF or other resources, you have possibilities for changing the look and feel of screen flows in ways that you might not have with any other Lightning App Builder components. For example, want to display fields in three columns? Not really an option on a Lightning page. But you can have a flow with three columns very easily! If you think about embedding a screen flow like that onto your page layout, it means that at least a portion of your page has all the design possibilities you can work with on a flow screen. Functional Screen Flows First, let's think "in-the-box." Screen flows were originally a way to take users through a guided script, with field updates, selections, and complex branching logic with automatic record updates. So they were originally conceived as standalone screens that users would work within. But in Lightning you can either have a screen flow take over the screen (like with a pop up) or embed it on the page. So consider where the flow will sit and how that impacts your overall design. Load right away? Consider that flows load slightly more slowly than most other page elements. So if you put your flow somewhere that's going to show immediately your users may see everything else load while the flow still has a progress spinner. (Not the end of the world, but something to keep in mind.) Still, if this is a flow users are going to use often, then right on the page makes sense. Of course you should also consider when users should take in the content and how they will interact with it. (Remember how eyes move around the page.) Hidden behind a tab? If this is a screen flow for users to do something they aren't doing regularly on this record page, that's a good time to put that flow behind a tab. As long as users can get to it with a click, it's going to still be easy for them. And the flow only loads when needed, which is good for performance. In a large or small section? It can be pain to test, but make sure you think about how your screen flow will appear based on the size of the section it appears in. If you're using the default page template with a small right-hand column, that's very different than the 50/50 split. Launched from an action button? If you don't want users to see the flow on the page itself, which can impact both the way the flow looks and the user experience, the out-of-the-box option is to launch the flow from a quick action added to the buttons at the top of the page. Launch Flow in Modal One of my famorite [free] components is Launch Flow in Modal from Salesforce Labs. It does exactly what it sounds like: allows you to put a button on your page that will launch your screen flow in a modal window (a "pop up"). And you can put that button on pages (like the Home page) that don't normally have actions. Screen Flows Only For Placement My final note is to remember that screen flows don't have to be for interaction at all. You could use one to just generate a block of content and then place that wherever you need. In this screenshot you can see an example: That block of text on the right column is a screen flow that has collected data from multiple related records, performed some calculations, and merged the results into a text block. Even though this is a screen flow, there is no intent for users to interact with it—it only exists for them to get the story told by the data merged into an understandable format. Effectively, this screen flow has become another way to include text on my page, one that I can design differently than fields and field labels. [Updated 7/11 with hat tip to reader Elizabeth Carena for pointing out the tip.] Note: You can't remove all buttons from a screen flow by hiding them. The editor will require that there always be at least one unhidden. But if you don't need any buttons, what you can do is uncheck Show Footer. Since the buttons show in the footer, that effectively removes them. Simple But Powerful I don't think I'm suggesting anything revolutionary here, just reminding you that screen flows can be part of your design thinking. But once you have that in mind, there are some potentially powerful additions to your design toolbox!

Call them what you want, but a record page, a Lightning page, an app, or anything else you work in in Salesforce is going to be displayed to your users as a web page. (Unless they're on mobile.) So the first thing you should keep in mind when you design your Salesforce pages is that people interact with your pages the way they interact with any other website. That means that [for speakers of left-to-right languages] eyes move across the page from top left to lower right, then bounce up to the middle of the window on the right, then work their way back across to the top left. More-or-less like this: A quick note here: I'm ignoring the Salesforce header bar. Your users do too. They've scanned this in the past from left to right and taken in the logo, search bar, help and profile icons, and the names of the object tabs. In everyday use, I believe they essentially don't even see this part of the page anymore. So when a new record page loads, this is the direction of eye movement across the part of the application you actually want to design for. Ignoring the Details Pane (for a sec) The first thing your users are going to train themselves to do is to ignore the details pane on the page—you know, all those important data fields! Not that details aren't important, but unless looking for a particular field, users know they don't need to get into the weeds of the fields when the page first loads. That's part of how the eyes can skim down to the bottom of the window quickly to take in the overall architecture, the brain knows that the details section has lots of information, but the data in the fields can wait for a moment. As designers, we are going to use that tendency to our advantage. Bounded by the Edges It seems worth nothing that we can also be confident our users' eyes are going to stay bounded by the window frame. Even the OS is designed to help us concentrate on the active window, not to mention the browser app design. And the user knows they need to stay within the focus window as well. So their eyes are not going to zip out of the frame before taking in what's there. General Principles I'll go through some of the most basic conventions I use in my page designs. Feel free to steal! Details on the Left (loading first) First of all, I'm a firm believer in loading to the details pane and keeping it on the left part of the page. (And, of course, thse pages are using the 50/50 template.). As noted above, this lets my users learn to scan the whole page design in a quick glance. If you load to a related list tab, first tof all they don't all load instantly. And second, I just don't think loading to related lists is usually what people need. Since I also always load to the leftmost tab in a tab component for consistency, that means Details will be the first tab. I hate the Salesforce default of making Opportunities load to the Related tab. Fields you want to draw attention to on the right, "above the fold" Using the newspaper analogy, I consider the bottom of the screen to be like the fold of a newspaper. Just as readers are more likely to read the first few articles at the top of a newspaper section, anything you can see before scrolling is going to get more attention. To that end, I love to use the Related Record Hack (not called that in the blog post) to put rollup summary fields or other important pieces of data in a prominent place toward the top of the right-hand column. By putting such rollup summary fields or other information over there, it's in the place that we know eyes are going to linger for a moment and, therefore, be more likely to get the attention we want. Banners Top Right (or Full Width) Notice another thing in the image above: There's a Lightning Messaging Utility banner in the top of the right-hand column. Again, it's where the eyes might linger. And it looks different enough from the rest of the page to catch the eye. Here's another example of a banner, this one across the whole page because it's meant to complement the Path component. Important Related Lists Upper Right You may have noticed in all these screenshots that I put the Related List Quick Links at the top of the right column. I think that's a super-functional component and a good place to make it easy to find the list you might want and work with it. I pretty much always put it in that position. (And check the box to hide the header! There's not much value to showing "Related List Quick Links." People know that's what they are.) But then I also put the most imoprtant one or two (or at-most three) single related lists in the right column. Those are the ones I think users are going to need to interact with most frequently, so I can save them clicks and time. Other Tabs Last, but not least, the eye comes to the tabs in the left column. I mentioned that the first-loading tab will be details. But you can have a whole bunch of other tabs here as well. As I said at the beginning of this series, consider taking fields off the details page layout and putting them behind tabs so they're easy to find with just a click. Make thematic tabs that have fields and related lists for a single purpose. We've got those eyeballs exactly where we want 'em. 🧐 Once we've thought about where focus is going it can help us start organizing our pages to guide our users to find the right information and work effectively. And isn't that what we're all trying to do for our colleagues?

When you're designing Salesforce record pages, you're not just placing fields for a database. This is the main application your colleagues spend their day interacting with, the place where they do their job. [At least, I hope that's the case! If not, you might want to spend some time searching out those shadow systems where people are keeping that critical data you need for reporting!] So if your colleagues are going to spend a good portion of their day in the system you're responsible for, perhaps you can give them some joy. Why be boring? Whoever designed your office (back when people had those) didn't just leave bare walls and a sea of cubicles. Usually. I think the same goes for our Salesforce orgs. Classic page layouts were functional, even if they looked oh-so-2003. But people expect more from computer systems in 2024. I bet you've had that moment when someone shares a screen or logs you into a system with a tiny font and icons straight out of Windows 95. It doesn't inspire confidence, does it? I'm advocating for making our Salesforce orgs look as well designed as the consumer websites we all access every day. (At least to the best of our abilities and within the constraints of Salesforce itself.) We may not have carte blanche to design however we want. But we have a lot of free and easy options most people don't take advantage of. I'm going to admit that this recommendation, comes with a bit of controversy, or at least a little need for nuance. Color may not work well for visually impaired users. Color choice is important. Web Content Accesibility Guidelines (WCAG) have opinions on color, particularly around contrast. I strongly encourage you to think about accesibility whenever you're designing. So please consider my recommendation to use color to implicitely mean "add color appropriately and with compassion." But the point still stands: Adding color to your page brings visual interest that will aid in understanding and speed for your users. A big green banner on a page layout lets most users know even before they read a single word that a record is "good," or "finished," or "complete." Trailhead makes this point very clear, "Visual aids increase retention from 10 to 65%." Here's a tiny screenshot of a record. I bet you have some idea of its status! There are a lot of ways to play with color in your org: Lightning Messaging Utility The banner in the screenshot above was created with Lightning Messaging Utility, a free app from Salesforce labs, which I've written about before. In a Formula Field There's a method from the stone ages for displaying an image saved in the Files library in a formula field. It works, I suppose. But as I've said when presenting, this requires you to be your own graphic designer creating those images. I can admit that mine were pretty ugly. Plus those images aren't screen-reader compatible by default. But you know what are good looking images complete with alt-text that are available on just about every device? That's right, let's hear it for emoji 🥳! Salesforce Indicators There's a really cool project from the Open Source Commons called Salesforce Indicators. Indicators is a free and open surce, easy to declaratively manage, Lightning Web component meant for adding visual...indicators to your record pages. Try it out! Sometimes Color Comes Free If you add a related list to your page layout, you automatically get the icon for that object. As a sysadmin you probably barely notice this anymore. But now that I'm pointing it out, consider how that pop of color draws the eye and [might] convey some information with the icon. Of course if you add a Related Record component with a Quick Action (my friend the Related Record Hack that I wrote about last post) you also get the object icon for that related record. Themes and Branding Don't forget that you can change up the whole look for your Salesforce by setting the background color and the logo. That kind of attention to detail will be particularly appreciated by your organization's brand managers. And it gives your Salesforce pages a pop that's different from standard Salesforce screeshots. The options here are nearly endless if you want to play around in ⚙️ Setup>User Interface>Themes and Branding. Screen Flows Last, but definitely not least, screen flows offer all kinds of ways to change up the look of a Salesforce page (or section). Whether with the standard components or some of the cool things put out by UnofficialSF, you can add color and visual interest to delight and entertain. Here I just used emoji to make a pretty basic screenflow more fun.

Recently I've been presenting at user groups and conferences on the theme of page design. How can you design your Salesforce to make your colleagues more efficient, accurate, and happy in their work? Too often we, as admins, don't take time to think about design and the user experience. These aren't new ideas. It's a while already since I wrote about the 50/50 split. (If you don't remember that post, I'll forgive you. I can sum it up: Don't use Salesforce's default Lightning Record Page template! Changing your template to give two equal columns lets your users take in more information more quickly when they look at records.) I'm going to assume that you're already working with a page template that can show your users the information they need. But let's go a step further than just the overall page frame. Let's ask, "Where am I putting fields?" Page Layout Editors Things don't get much more fundamental in Salesforce than page layouts! You've got two fundamental editors for your page layouts: The "enhanced" [before I even got into the ecosystem] page layout editor. Basic and functional. New-and-shiny Dynamic Forms right in the Lightning App Builder. Let's start by thinking about where you put fields, not how you get them there. Go ahead and use whichever tool you prefer. Both have their pros and cons. The considerations for placement don't change. If There's a Need, It Leads Most of your required fields should be toward the top of the page layout. You probably already knew this, but it's worth specifying. And I bet now that you're thinking about it you can come up with some places where you could do better. Ever have that problem where you're trying to throw together a quick test record and you can't do it without scrolling all over the page to fill in a bunch of required fields that aren't grouped? So frustrating, right? Perhaps that means the page layout needs some love. If there are fields without which a record would be entirely meaningless—or even impossible (such as those required at the database level)—then your users are probably planning to fill them from the moment they click New. Help them with this. Put required fields right at the top of the page, in the first section a user encounters. Even if a field isn't actually required on the page layout, the sooner a user comes to it on the New Record screen, the more likely they are to fill it out. Make that first section count! Of course the most obvious example here are Name fields. Just as the First Name and Last name fields are the first and second fields you expect to enter when creating a new contact or lead, every other Salesforce record has a name field of some kind. If it's one your users will fill, put it in the top left spot—the first field they encounter. Auto-numbered records don't accept user input for the name, so they aren't a factor for data entry. But I still prefer to put an auto-numbered Name field pretty close to the top. That way when we need to refer to it we know where to look: in the same place we would look for any other record. If we're talking about a record that has a Stage (or Status), such as Lead, Case, Opportunity, or so many custom objects we've all built, I'm going to argue these probably go pretty near the top as well. And that brings me to the next principle. Like Things In Like Places Those Stages (or Statuses) are important, so they're going near the top of the page. And generally I want to put them in a similar location for all objects. That way, even without thinking about it, on any record my users know where to glance to find the current stage. On my pages these fields are usually at the top right of the first section on the page. My users get subconsciously trained that whenever there is a Stage, it's a picklist they adjust at the top right, probably next to Name. Actually, I think I got trained by Salesforce. The default location for Stage on an Opportunity page (in Classic) is toward the top right. That's probably how I got into the right-column habit in the first place. Of course, there are all sorts of other ways users are going to interact with Stage, such as with a Path component, through Lightning Messaging Utility banners, through a Quick Action, or perhaps the stage changes through automation. But whatever underlying field is represented by a Path or banner I also put directly on my page layout. That ensures ease of editing in the full Edit modal, makes it available to adaptive tools like screen readers, shows it in obscure places like the printable view, and even makes it available for editing in list views. Got an object with a Start Date and End Date (like Campaigns)? Make sure you keep them together! There's nothing more frustrating than entering the start date and tabbing into the next field only to find that it's not the end date. I tend to put record Owner on the right and toward the top for any objects where it's actually used. There are other reasonable placements, for sure. Just be consistent. [If Owner isn't important for your organization there a few objects you won't be able to remove it from. In that case, bury the field somewhere it won't be obvious, probably down with the rest of the system fields, so you at least reduce the visual clutter.] Speaking of which, you have to decide how you feel about the system fields. There's a valid argument for taking Created By, Created Date, and Last Modified Date off the page to just reduce overall clutter. On the other hand, particularly for sysadmins, these can be very helpful fields. I leave these on all page layouts, even for simple objects with just a handful of other fields. I also keep the default System Information section, I turn on the header display at all times, and I leave the section at the bottom. I usually even add one more blank space between the last substantive field and the header of this section. For those users that know, they can collapse the section and it will stay that way for them in the future. And even those that don't collapse it have that extra space to clue them in that they can stop reading before that last section. Consider Removing Fields I mean it. There are fields you don't actually need to be on your main page layout. "Main layout" meaning the "Details" component of most Lightning Record Pages. There are all kinds of fields you can move off the details section and put behind a tab or somewhere else on the layout. NPSP has dozens of donor rollup fields, for example. Most users aren't looking these when they go to a contact page. And if they are looking for the rollups, it's easier to find them with one click behind a tab than to scroll down looking for the right section. Fields that users don't edit, like rollups, are great candidates for putting behind a tab. You never need them to show up when the user clicks Edit and gets the fullscreen editing modal. With Lightning there are all kinds of other field moving possibilities. If you have a handful of fields that are only edited occasionally, and only together, not in the context of other record updates, you can put those fields together behind a tab. Teach your users that's where the fields are and that they can edit them using the pencil icon. Bam! Now you've made users more efficient (fewer fields to wade through when editing) and happier (able to see just the fields they want when they want them). You're a hero, just by taking some fields off the page layout and putting them somewhere else. The How of Moving Fields Around Now that you're thinking about why, when, and where to move fields, let's take a moment for the How. There are two ways you can do this: The Related Record Hack My preferred field moving method is known as The Related Record Hack. Despite what I call it, this is a Salesforce-built and -approved feature. As described in this post I wrote on that other blog several years ago, you create a Quick Action and place it on the page using the Related Record component. "Hack" in the nickname refers to the fact that you accomplish it using a Quick Action and a Related Record component, though it's neither to take any action nor to display a related record (just the record itself). Dynamic Forms Clearly Salesforce is moving in the direction of Dynamic Forms. Using Dynamic Forms you can place single fields, build field sections, and conditionally hide or display as you desire. Full disclosure: I'm not using Dynamic Forms yet. There are a handful of limitations and frustrations about the feature that have kept me away. Each release is making this feature better, for sure. In truth, the main thing holding me back is that I switch between orgs so often. It would be a pain having to constantly juggle between the two methods. That was Just Step One Who knew I would have so much to say just on the topic of moving fields around on your page? But this is just the beginning! There are all sorts of things you can do to make your Lightning Record Pages more fun and interesting, including adding color, directing your viewers as they scan your page, and more. Watch this space.