We used the 'Tabs' standard lightning component in Lightning App Builder to create a tab layout like below. The question is, is there a way to set the default tab dynamically in this standard component WITHOUT creating a custom component? Say, via a custom parameter in the URL (like use something like #my_tab_id_to_view at the end of the URL like several websites out there today do or perhaps &tabToNavigateTo=my_tab_id_to_view?) or some simple/quick JS hack or ANY (hidden) way at all? I know this is possible if I leverage lightning:tabset within a custom component, but the idea is to use as much native as possible.

The ultimate goal is to open a selected record within the context of it's parent record. That is, (please refer to below) if an end user clicks on an 'Agreement' record or a 'Creditor' record or an 'Open Activity', it must first ALWAYS redirect to the parent DS record, BUT automatically open the selected Agreement or Creditor or Open Activity within it's corresponding tab (or sub-tab) within the DS detail view. Redirection I can do, but defaulting a tab is what I am here for.

Tabs Layout

  • There's a "Default Tab" property for Tabs component, does that solve your purpose? – Jayant Das May 11 '18 at 13:41
  • No, because that would be static. I am looking for a way to set the default tab in native component dynamically. – Lightning Evangelist May 11 '18 at 13:43
  • 2
    That's right. And I don't think you will be able to do that dynamically within the native components. – Jayant Das May 11 '18 at 13:44

All the Standard Lightning Components (unless documented otherwise) do not contain events/attributes you can interact with publicly, they are kind of little black boxes. Unfortunatelly, as soon as a change of behavior is required, you basically need to code your own component from scratch.

You can also check your org's aura docs for these at:



Based on all my experience so far, there's no way to achieve this. The solution you are looking for is basically communicating between components. However this approach is only available with custom components whereas in this case it's standard components provided by Salesforce which is kind of abstracted and encapsulated from the developers and that there's no control to manipulate those.

I would also think that this layer of abstraction is necessary from product perspective to an extent as exposing any attributes which is utilized by the core platform can lead to security threats. Consider why we have Lightning Locker Service, even though by utilizing the custom lightning components in the namespace great features can be achieved, but there's always a guard rail in form of Locker Service to make sure while utilizing those components, no security issues are compromised.

Your Answer

