Compact Layouts, De-Mystified

We've been studying for our Platform App Builder Transition Exam, and one of the topics listed in the study guide (and in SalesforceBen's helpful post) is Compact Layouts.

In short, according to the Salesforce Help site, "Compact Layouts are used in SF1 and Lightning to display a record's key fields at a glance."

We were already familiar with these to some degree, as we actively use them in our own Salesforce org:

 
opp name, stage, close date, amount

opp name, stage, close date, amount

 

...but in studying further and trying to learn all the details, we got a little confused! Now that we're un-confused, we are here to share our newfound knowledge.

We read the documentation (about 47 times) and noticed something strange, so we asked The Internet:

All the documentation talks about adding 10 fields to the Compact Layout, but all the explanations of how they get used seemed to only talk about fields 1 through 5.

Turns out we kept missing a key line in all of those help materials, which The Internet helpfully pointed out for us:

Right there in the "overview" lesson (and in the release notes), it says "In the full Salesforce site, compact layouts determine which fields appear in the Chatter feed item that appears after a user creates a record with a publisher action."  

We're still not sure how we missed that sentence every time we came back to this page! We think it's because the "definition" of these layouts is always described as being about mobile and Lightning, so we weren't expecting the fact that they get used in SF Classic as well; also, we started learning about these from the SF1 Mobile lesson in Trailhead, which doesn't talk about their application in SF classic for obvious reasons.

We tested this and sure enough, it's true:

4 fields...

4 fields...

 
...more than 4 fields! (though you still need to click "more" to see all of these)

...more than 4 fields! (though you still need to click "more" to see all of these)

So! There's the answer to why compact layouts support up to 10 fields!

If you're not using them yet, you totally should! It's the closest thing we have right now to this popular Idea in that it allows you to bring certain fields to the top of a record in SF1 that might not need to be at the top in SF Classic. For example, our Opportunity page layout are huge, and organized into sections that make sense and are helpful when you're using a browser on the desktop, but there are important fields scattered all over the page that we can pull together into a compact layout so they're still visible at a glance on our phones.

Spring Cleaning: Contact record fields

We have a demo account that our sales team uses to show our prospects PatronManager. It's about five years old now and showing its age -- there's lots of weird historical data, and lots of accumulated one-off customizations that weren't ever really documented because it's not a "real" account. There have been lots of users over the years, all of whom have had System Admin privileges.

Our company and our sales team is growing, so it was time for a reset. Most of the accumulated mess hadn't been a day-to-day problem, because the old-timers on the team knew how to work around the things that were messy, but as we've hired new people, they've had to get started without the same benefit of experience.

So we decided it was time to create a brand-new account. We imported a bunch of more-realistic historical data in order to be able to do better demos of reports and dashboards, and then it was time to tackle the fields and page layouts.

And then we realized that the lessons we were learning and decisions we were making applied to other scenarios as well -- like, anyone who's inherited an older Salesforce or PatronManager account that hadn't been cleaned up in a while.

Here are the facts we were working with:

  • There were lots of custom fields that were sometimes nonsensical (like "Dog Person or Cat Person?"), often duplicative ("VIP" vs. "VIP?"), and frequently one-time use only (like "My New Field," created on the fly to show how easy it is to create a field! ...and then left there to rot on the page layout).
  • Page layouts varied wildly and without intention -- someone would occasionally pay a bit of attention to cleaning up or reorganizing the "Individual Account" layout, for example, without taking the same care with the "Household Account" layout.
  • There were custom badges of all different color schemes and styles because they'd been created at different times by different people using Da Button Factory or something similar (which is a site we love, but stylistic consistency would be nice).
  • Certain contact records looked okay because they were the ones that were used all the time -- they had all their fields populated with data that made some amount of logical sense for being a "real" person… but little attention had been paid to the vast majority of other records, so many were incomplete or obviously fake.

Peggy Olson's contact record, before.

In short, if this were a real client account, it would be impossible for people to get anything done, which made it a pretty terrible demo situation.

We needed to fix things.

Here's how we did it:

  • We designed a whole new set of badges and did a serious audit about what they all meant and how their formulas should be written. The old account had one badge field for Major Donor and a whole different badge field for Lapsed Donor -- we combined those together and added in a few more options to make a single coherent Donor Status field.
    • There were also separate badge fields for "VIP" and "Notable Patron"... we decided that was too weirdly similar so we cut the Notable Patron badge (because our users, the sales team, said they preferred to keep the VIP one).
  • We found and destroyed all the one-time use fields by running reports to see if the data was ever populated anywhere… mostly it totally wasn't, and if it was, the data was meaningless.
  • We reorganized all the active page layouts to help keep things organized and easier to understand at a glance, in a demo situation.
    • We made a new section specifically for fundraising data.
    • We're using a mini-Visualforce page to show donation history, so we moved that to its own section, without a header.
    • We added "blank spaces" to sections that needed more balance.
    • And we made sure to think through these changes, not just focusing on the fields that exist right now, but to make sure there will be logical places to put new fields that might get added in the future.
  • We checked our work both on the frequently-used records with complete data, and also on the records with less-complete data to make sure things didn't look super weird or confusing in either case.
  • All of this was done in the new, yet-unused account, so we had lots of chances to communicate with the team and show them things and get approvals.

Peggy's contact record, after

Everything looks so much cleaner and more usable now! The badges communicate the most important information about a contact, and it's easy to tell where to look to find the thing you're looking for.

We did the data evaluation work "by hand" in this case, by running reports and using our eyeballs, but we've also recommended the Field Trip app to clients who are interested in evaluating their use of fields in a more sophisticated way.

We would follow pretty much the exact process if we were working in a "real" account, with one exception: instead of doing all this work live in production, it would be done in a sandbox instead and then deployed after getting approval. (Though actually we've found that for MINOR changes to layouts, we can work directly in production -- we'll create a new Layout, and use Page Layout Assignments to assign it only to the person doing the work, and getting approvals from other stakeholders by posting screenshots to Chatter.)