Lightning Layout Tricks: Record Detail Tabs

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 recently shared how to use Conditional Record Detail Components and I’ll be posting a few more over the days to come.

I hope the community will share some of your super Lightning Layout Tricks with us as well.

*Shoutout to Christine Marshall who posted this same concept after I posted a much lamer idea in the Answer Community several weeks ago.  I completely forgot about it, but clearly she inspired my subconscious!


Record Detail Tabs

Use Case: Universal Promotions’ admin, Kenny, has been asked to shorten the page layouts so users have to scroll less and find the fields they are looking for faster.

Build Requirements: Create ‘Update Records’ Quick Actions, Lightning Record Page, and Lightning Tabs Component


Example: Universal Promotions is an approved vendor to provide promotional items to MLB Baseball teams.

The Sales Manager, Kristi, believes the account pages have become cluttered with fields to track address information, details about the teams’ stadiums, and important contacts.  Kenny has been asked to come up with a solution that will organize the fields, minimize scrolling, and provide users with fast access to the fields they need.

In Classic the only solution was to build a custom Visualforce page, but #AwesomeAdmin Kenny knows that with Lightning, he can deliver this functionality with clicks, not code.


The Build:

Review your fields and determine how they should be grouped.  In this example, Kristi & Kenny have decided the fields can be grouped into 3 categories: Addresses, Stadium Info, and Key Contacts.

Create one ‘Update a Record’ quick action for each grouping, giving it a descriptive name, and then adding the desired fields to the quick action page layout.  Repeat this process for each group of fields.

Now that you have your actions, you’ll need to edit your existing or create a new Lighting Record Page.  Add the Tabs Lightning Component to the page layout, naming the tabs to match your field groupings.  Add the Related Record Lightning Component to each tab, selecting the appropriate Update Action to match your tab name.  Save/Activate.

Edit or Create a new Lightning Record Page

Add the Tabs Lightning Component and name each Tab to match your quick actions & field groupings. 

Add the Related Record Lightning Component to each Tab, configuring it with the corresponding Update Action and then Save/Activate.


The Result: Record detail fields are now displayed in tabs instead of down the page, allowing users to quickly see fields in groupings rather than scrolling.

Addresses Tab

Stadium Details Tab

Key Contacts Tab


Additional Use Cases:

  1. Opportunity Stages: If your selling process involves very specific tasks/fields for each stage, you can use this approach to create tabs for each stage, using the primary page layout to capture header level information.
  2. Conditional Tabs: Display header level information to some users, while making the tab component only accessible to those who should have access (see the prior post in this series for more information).
  3. View/Edit Related Object Record: For any lookup field on the object you are viewing, create a quick action on that related object. You can add that Update Quick Action to the Related Records component, pulling key fields from a related record onto the tab layout for users to interact with from the current record.
  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!

Comments

  1. Daryl Moon says:

    This is a great trick for breaking up long record detail pages but validation gets trickier as the details for the fields in these three new tabs don’t get added when you create a new account record. One workaround (not perfect) is to add a validation rule that tests if the account record already exists first and if it does not exist then allows the validation to be ignored. The validation rule (shown below) then only runs when you edit the record a second time and checks if the BillingStreet is blank.

    To test the Billing Street has been added you could use:
    ———————————————————
    AND
    (
    NOT(ISNEW()),
    ISBLANK(BillingStreet)
    )
    ——————————————————–
    This says IF the account record is NOT new (it already exists) AND the BillingStreet is blank then display an error.

    I’d be interested to see if there is a better way to validate these fields.

    • Tom says:

      That is a fantastic point, one I had not considered. In trying to make it more user friendly, you run the risk of reducing compliance.

    • Tom says:

      Great add Daryl, the Not(IsNew()) is your best friend for general record validations when using these.

      If your tabs are conditional, you’ll also want to include your condition in the validation rule so it does not fire when a tab is not visible.

      To my knowledge – the Not(IsNew) or CreatedDate<>LastModifiedDate are the two ways for making this work via validation.

  2. Ted Hazard says:

    Fantastic post. Thank you for sharing such a creative solution. I can’t wait to share with my team and local user group. I’ll (try) to come back & update the comments when we decide how to implement this in our Org.

    • Tom says:

      Thanks Ted!

      I have not found the right use case to implement myself, so right now its just a fun idea looking for a problem to solve.

  3. Chris says:

    I’ve created this for my org but it has got a big flaw I can’t get around. Conditional Fields – I had to disable them to get it working otherwise you couldn’t edit some of the fields.

      • Tom says:

        Yes – quick actions will not display images like the google maps, any formula images, etc. It is a limitation of the approach, same with dependent picklist values.

        It is a great approach and until there is a method to use editable field sets within a Lightning Component, I’m afraid we have to live with the warts from a declarative perspective.

  4. Kim says:

    I am so happy to have found this post! Basic question – is it correct that inline editing is the only way to edit fields in a Quick Action, i.e. those fields will not appear when you click the Edit button on a record?

    Thanks again! I can’t wait to start rethinking my page layouts.

    • Tom says:

      Hey Paul – unfortunately, this does work well for mobile layouts.

      In theory, you could add the quick actions as buttons on the SF1/Mobile page layouts, so when they are viewing the opportunity, they could click the quick action for each individual stage.

      Its not ideal, but it should work.

    • Tom says:

      Thats a fantastic question – I’ve honestly never tried but my initial thought is no since they dont use the same components in the community. I will have to check this out though.

  5. Jasmine says:

    My org has several visualforce sections in the Details of records so there is a lot of scrolling in Lightning. Is there a way to make tabs for those in the same mannor? Or would it cause more of a headache than just scrolling just a bit further?

    • Tom says:

      You can try adding the Visualforce Lightning Component to your lighting page and selecting your VF Page, if that does not produce the desired results, you may need build those VF pages into lightning components, but then you can assign those components where you like on the page, including in tabs.

Leave a Reply

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