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.