Lightning Layout Tricks: Conditional Record Detail Components

Recently I’ve been working with some fun ways to use the Lightning Page designer & various Lightning component to create better end user experiences.  I’ll be posting a few more and hopefully the community can share some of your super Lightning Layout Tricks with us as well.  

Latest entries in series here: Create Record Detail Tabs, Use Page Layouts for Mobile/Classic/Create only, and create a Demo Controller.

Conditional Record Detail Components

Use Case: Universal Promotions’ Salesforce admin, Kenny, has been tasked with showing different, editable fields for each record depending on that records characteristics.  In the past, Kenny would create new record types, page layouts, and workflows to manage this request, but with Lightning Experience, Kenny has new admin super powers to deliver a cleaner, simpler solution.

Build Requirements: Create ‘Update Records’ Quick Action(s), Lightning Record Page, and Related Records Lightning Component

Example: Universal Promotions is an approved vendor to provide promotional items to MLB Baseball teams.  Based on a teams total spend during the prior year, accounts are assigned a customer level; Platinum, Gold, Silver, or Bronze.

For the current season, Universal Promotions’ sales manager, Kristi, has set two growth targets for all the accounts based on their current level.  Kristi wants Platinum accounts to grow by 8% minimum, with 15% as a stretch goal and Gold Accounts to grow by 5% minimum, 10% as a stretch goal.

She wants her sales team to see those goals on the account page based on the current level and to not appear for new customers, who have not been assigned a level.  Kenny realizes that with Lightning Experience, the traditional method of multiple page layouts, record types, and workflows to update record types is a thing of the past and instead will use Quick Actions & Lightning Components to deliver a more advanced solution.

The Build:

Create a quick action on the account object.  The action type will be ‘Update a Record.’

Assign your fields to the page layout & hit save.  You can ignore the message about required fields, it won’t apply to this quick action.  Create one quick action for each conditional set of fields you would like to display.

Next, edit or create your custom Account Lightning Page.  Drag & drop the Related Record component onto the page, one per each level.  Give your component a label like below, select the appropriate Update Action, and lastly, set the component to only be visible when for the corresponding Account Level.  Once you have repeated this for each Update Action, save/activate your Lighting Page.

Edit or create a new Lighting Record Page

Add the Related Record lightning component to the page and configure it to use your update actions. 

Add your component filters. 

The Results: As you change the account level, the conditional components appear, displaying the goals for the current year.

Gold Level

Platinum Level

Additional Use Cases:

  1. Eliminate the need for Account Record Types: If the only reason you want to create a new record type is to display different fields, simplify your build, stick with a -Master- record type, but use conditional components + quick actions to display editable field components based on the Account.
  2. Display fields to specific users only: Minimize the use of page layouts by profile, instead use the current user’s record to conditionally display fields in a related record component.  To understand how to reference the current user, see this post. 
  3. Lock Fields: Create two quick actions with the same fields on it, marking the fields on the page layout for one action as read only, while allowing the others to be edited.  You can now display the fields and allow them to be edited based on the record status and then display the read only fields when you would like them to be ‘locked.’  You can prevent annoying users with validation rules and also avoid issues with integration and data uploads that may conflict with validation rules.
  4. And more:  I can come up with a dozen more, but hopefully this is enough to stir your imagination and I would love to see your ideas in the comments below!


  1. Vicki Harrell says:

    Is there a way around validation rules? You can’t save the record until the required fields are populated, but you can’t see the required fields in the conditional record detail component until the record is saved. Use case: hide the client fields until the account becomes a client. Several client fields are required.

  2. Tom says:

    Hi Vicki – I would make the fields required on the quick action layout and then change your validation rule like this:

    AND(Not(IsChanged(ClientField), ClientField=True, OR(IsBlank(Field1), IsBlank(Field2), IsBlank(Field3)))

    I have not tried this before, but I think this should not fire when the client indicator is initially changed, but then subsequently will be required. Feel free to reach out to me via chatter ( if you want to discuss more.

  3. Dilip says:

    There is an issue with this, if a profile do not Edit permission on the object. Then complete layout fields in related component layout gets disappeared though they have profile user has read access. Surprisingly all the compact layout fields are getting displayed in the record detailed component.

    • Tom says:

      Yes, this is not a perfect solution; there are exceptions like users need to have edit access to take advantage of this feature.
      There are other tools that can display a static field set in a component that are on the app exchange.

  4. Glenda Ninan says:

    This solution unfortunately does not work great in terms of performance if you have more than 10 fields on the Page. I have more than 20 fields on my page. What I noticed is that all my other Lightning Components have been displayed while my Quick Action page is still empty. I hope there is a workaround to this issue.

    • Tom says:

      Hi Glenda – I’ve had up to 50 fields on a quick action before and have not experienced any issues, what limitations are you experiencing?

  5. Alexis Willis says:

    @Tom Could I use this technique to alter which contacts show in single related list lightning component dependent on whether a checkbox is checked in the related contact record?

  6. Catia says:

    Hi Tom, inspired by your post I decided to try it out in a business case – I’m a beginner in SFDC. The issue I’m facing is related to controlling/dependent picklists; I’d like to keep my card as short as possible but I cannot edit the dependent list if the controlling isn’t in there in the layout – even though the controlling list option was already defined/stored. Any tips to overcome this issue? Thank you so much in advance!

  7. Kevin Circl says:

    Awesome solution, had no idea we could use a quick action to conditionally display data as a component, thank you! I just tested in my dev org and will role it out to production soon. Makes the wait for conditional fields on page layouts coming in Winter ’21 easier to take.

Leave a Reply

Your email address will not be published. Required fields are marked *