Usability Wins with Dynamic Lightning Pages in Salesforce
When Dynamic Lightning Pages first became available, I admittedly thought of it just as some flashy Lightning enhancement without much practical implication. “Nice, filter visibility of a component based on a field. Moving on…” Since then, though, I’ve found some really powerful ways to solve for common requests, including things that were previously a no-go.
The Big One: Personal Homepage
This was quite literally a eureka moment. I was working with a client’s admin whose team was complaining for the 100th time that they couldn’t have their own personal dashboard always on just their home page and no one else’s. I started on the old ‘well, Home Page is based on Profile’ refrain but stopped mid-sentence, was silent for a moment, then said “Let’s try something.”
It is well advertised that you can filter visibility of a Lightning Component on a page based on a value of a field on the record, but did you know you can also filter visibility based on something about the current User viewing the page? That’s right, a whole new layer of customization of what a user sees that can be based on pretty much anything about that user you could imagine storing in a field on the user record, not just their profile.
When adding or editing a component on a Lightning Page, you will see the option to Add Filter under Set Component Visibility in the right-hand panel. On most pages, the ensuing pop-up defaults to Record Field and has a selection for Advanced, but on the home page you just get a button to select a field--this is the same functionality as would appear if you chose Advanced on a Lightning record page. In the Select A Field Dialog, clicking the down arrow reveals the word User, which takes you to a list of fields on the User record to select from to leverage in your filter.
The big win I see with this is the ability to have customized homepage layouts without proliferating otherwise unnecessary profiles. Special execs can have that dashboard they always dreamed of right on their home page without messing things up for everyone else. It’s an easy way to make users happy without adding complexity to your overall implementation. This could also be leveraged with other home page elements that are only relevant to certain sub-groups of users or by request, kind of like how permission sets can be used for one-off functional user needs.
The gotcha to remember is that this is a Show vs Don’t Show scenario, not show-something-different-based-on-a-value scenario. Any complexity of logic can get unwieldy because you need to add a separate component with its own filters for each scenario. So word of caution to use this power sparingly, to avoid messy to manage Lightning Pages.
Other Goodies
As I mentioned the User filter works on record pages, too. A use case for this I’ve come across is when only certain users have access to an app that delivers its functionality in Lightning Experience via a component, such as a document generation tool. Depending on the setup, it is possible that users will see this component even if they don’t have access to fully execute the functionality it exposes, which could result in confusing errors or simply unnecessary clutter for users who do not need to use this component.
All this talk about user filters is not to dismiss the value of record field filters, either. Going back to the document generation component example, if the document can’t be generated, say, until a record has been approved, an approval process that updates a field that then controls the visibility of the component is useful. You can even combine record field filters and advanced filters to get the desired result.
One great example I’ve come across in using record field filters in component visibility is when leveraging another very cool feature of a certain standard Lightning component- the Related List- Single component. With this component you can display a related list from a record related to the current one via a lookup or master-detail relationship. A great example of this is with Accounts and Parent Accounts--you could display, for example, the Opportunities related list from the Parent Account to get a more robust picture of the value of this relationship to your organization. The gotcha is that you get an unsightly error in the component display if there is no Parent Account related to a given Account to display the related list from. While you can’t directly filter component visibility based on the lookup field itself, you can build a formula checkbox field to return “true” if the Parent Account field is populated on the record and filter the component visibility based on this. No more ugly error!
Dynamic Lightning Pages are another way we as Salesforce Administrators are more and more becoming user experience designers. It is important to consider the full user experience when defining component visibility, whatever it is based on. Leveraged with consideration, this feature can provide great usability improvements for your team.
Do you have creative examples for leveraging Dynamic Lightning Pages? Feel free to comment on the Salesforce Success Community or directly at me on Twitter @ifitfloats.
