What a Salesforce Lightning Record Page is and what you should do with it, is one of the toughest conversations when I’m transitioning a client from Classic to Lightning.
This most likely overwhelms people because we are introducing another layer on top of understanding how page layouts, record types and field-level security work together! I remember one particularly exasperated client exclaiming, “Why on earth would Salesforce add this thing!? Our layouts were fine!”. I politely explained that their layouts aren’t going anywhere and that if they give me a few more minutes, I can not only show them why Salesforce added them but also make them fall in love with Lightning Record Pages – which is what I will also show you in this article!
You might seem dubious about this if you’re new to Lightning – I don’t blame you. When Lightning came out, I had a lot of resistance to switching, and It wasn’t until Winter ‘18 that I got really excited about the potential of Lightning. Why? Component Visibility – it’s a game-changer!
Here’s the article from when it launched, and is a great introduction to Salesforce Component Visibility.
As I promised, I’m going to make you fall in love with Lightning Record Pages, by highlighting a few of my favourite things that I’ve discovered.
1. Simplify & Consolidate
I can’t tell you how many times I’ve logged into a client’s org for the first time to make some requested updates to a Lightning Record Page and I come to list like this:
I’ve found there are two main reasons for a list like this to exist:
a. An Org Default was never set, and a new page was saved each time the admin clicked Edit Page from the Setup menu while on the record.
b. A new page was created by the admin each time different users requested a change to the page.
Simplify these pages by consolidating the experience into as few pages as possible. Both you and your users benefit from this, because the next time a change is requested, you can more quickly identify which page to change. Naturally, your users will love that you’re able to turn around their request so fast!
2. Set Alerts!
When I first became a Salesforce Admin, I remember there was a request to show on the account when a customer escalates a case to Tier 2 support. The wish was a big banner that could not be missed, and they wanted only their Tier 2 team to be able to put the banner on the account. Back in Salesforce Classic, this was a tough sell when it came to priority against other goals. Sure, we can make a checkbox only Tier 2 can see/edit, but making a dynamic Visualforce component to show on a page layout was beyond us at the time.
In Lightning you can still use that checkbox – but, in the Lightning Record Page, you can drop a Rich Text Component and format a message that will show for your users. Here’s the filter in my component visibility:
Then when that box is checked, your users see the lovely banner you created:
My example used a checkbox that was updated manually, but there are so many other great use cases I’ve seen. You can use it to enforce data integrity by indicating that something is missing, or to traverse records – for example, let’s say you’re on a case and you want to remind users that the associated contact is missing an email address. Just click on the Advanced tab in the Component Visibility and navigate to that field on the contact:
You can set it based on the:
- running user’s information,
- record owner’s information,
- permission the running user has
- the user’s device (see image below:)
3. Share Instructions
Have you ever wanted to give users a little more to go on than just Help Text? Or maybe you’ve got users hounding you about how to do something repeatedly? Or maybe some third-party vendor gave you a custom component that works great, but only under specific circumstances? Well, similar to the Alerts section above, the Rich Text Component is your new best friend.
I use Component Visibility to tell the user what they need to do to get the component they need to show up. Let me explain: I use to Component Visibility hide a component that has what the user needs, eg. a form or button, and use the opposite logic on a Rich Text Component to tell the user what they need to do to get the component to show up. When they take the desired action, the component will show.
Why not Validation Rules?
Now, you might be wondering why I wouldn’t just use Validation Rules for this? Don’t get me wrong, I still use Validation Rules for this in many circumstances because it helps enforce data integrity. However, the one thing Validation Rules lack is telling you up-front what you need to do, and if there are several rules, do you really want a user to keep attempting to save a record just to see what new error will show up? That can be pretty frustrating. Instead, if they have a simple bulleted list to verify, they will more often only have to save it once*.
*but, still back this up with Validation Rules for data integrity.
4. Training Wheels
Following on from Instructions, ‘Training Wheels’ are another great use case.
If you’re about to launch a new org, I would suggest for you to still be a part of the training (even if you are not conducting the training). Sit in the back of the room and find out what questions people have, think about what questions they’re going to have.
You can litter answers all throughout the system: on the home page, on record pages, for different profiles, or even down to a specific user who keeps forgetting the steps to log into their phone. Make a “Training Wheels” checkbox on the User object that all these instruction components are pointing to on the running user’s record. Once they’ve got the hang of the system you just uncheck the box and they are no longer bothered by the tips you created for newbies.
5. Leverage Formulas
I’ll keep this simple, because formulas and Component Visibility could lead us into a deep rabbit hole. You can make infinitely complex formulas that component visibility work from.
So, why use formulas instead of just adding multiple filters in your component visibility? You can only set 10 filters currently, and you may want more complex logic than this.
When it comes to using (potentially insane) logic to determine if someone can see a component, formulas are your go-to tool. You don’t even have to display it on the page layout, just let it do its thing in the background and then use it in your filter. You might have a checkbox formula with tons of nested “if” statements that takes days for the average human to decipher, but your component visibility filter just asks if it’s true and goes about its business.
6. Custom Permissions
I’ll finish this out with something that was a bit of an afterthought to me for years: Custom Permissions. Yeah, I saw it on profiles – yeah, I saw it in permission sets – but it was always empty, so I ignored it.
Then one day, we were designing a new feature that had layers of permissions that was going to be hard-coded in Apex and I thought, “I wish there was some feature where I could assign a permission, but make a custom one…wait, I feel like I’ve seen something like that.” And thus, I found Custom Permissions.
What does this have to do with component visibility? I’m glad you asked!
Earlier, I briefly mentioned you could show a component based on the running user’s permissions; well, that just so happens to extend to Custom Permissions.
Go into Setup, find Custom Permissions, make whatever permissions you want, set your component to be based on that permission being true and then assign that permission however you’d like:
I hope that this article lived up to its promise – to make you fall in love with Lightning Record Pages. In this article, I’ve highlighted a few of my favorite things that I’ve discovered, but honestly, there are so many more things you can do!
You may even have thought of some uses for component visibility in your org as you read this post, so I’d love to hear about them in the comments below.