Per the force:hasSObjectName interface documentation, I can reference an automatically added attribute named sObjectName to retrieve the object where my custom lightning component is being accessed. However when I try to use this value, it is undefined (code below): Is this the correct way to reference the sObjectName? I'm aware I can pull this value from the record id, but I'd like to know what I'm doing wrong.

Lightning Component

<aura:component controller="lc_BuyerSellerSearchCriteriaCTRL" implements="force:hasSObjectName,force:appHostable,flexipage:availableForAllPageTypes,flexipage:availableForRecordHome,force:hasRecordId" description="lc_BuyerSellerSearchCriteriaDynamic" access="global" >
    <aura:handler name="init" value="{!this}" action="{!c.init}" />
    <!--Component Code-->

Component Controller

init: function(cmp, event, helper) {

This statement in the console log shows undefined

  • 2
    Is your component placed on the record context, viz., record layout?
    – Jayant Das
    May 22, 2019 at 16:22
  • It's embedded within a custom tab on the record layout May 22, 2019 at 16:32
  • That should still work fine. You should verify if there's something else going in your init function which is blocking the component to be rendered completely. I can confirm that it works if added to a custom tab.
    – Jayant Das
    May 22, 2019 at 16:36

1 Answer 1


With a quick test I can confirm that this works fine as long as your component is within the right context. The same is mentioned in the documentation (emphasis mine).

Important The sObjectName attribute is set only when you place or invoke the component in an explicit record context. For example, when you place the component directly on a record page layout, or invoke it as an object-specific action from a record page or object home. In all other cases, such as when you invoke the component as a global action, or create the component programmatically inside another component, sObjectName isn’t set, and your component shouldn’t depend on it.

These unsupported contexts include a few contexts that might seem like they should have access to the current record. Examples of these other contexts include the following:

  • Invoking the component from a global action (even when you’re on a record page)
  • Invoking the component from header or footer navigation in a community (even if the page shows a record)

force:hasRecordId and force:hasSObjectName are unsupported in these contexts. While the marker interfaces still add the relevant attribute to the component, accessing either attribute generally returns null or undefined.

You will need to verify that the component you have is placed within the correct record context.

  • Is a custom tab on the record's layout (ie next to the record's standard "Details" tab) not explicit enough context? May 22, 2019 at 16:43
  • It is. And I can confirm that it works in that context too. As soon as you click on the Tab, your component gets initialized and you will get the sObjectName.
    – Jayant Das
    May 22, 2019 at 16:45
  • The force:hasSObject interface works when the component is directly on the record layout page but for the same component it doesn't work when it is on a custom tab on the same page. The component in question is a child component within a parent May 22, 2019 at 16:49
  • It won't work that way. It has to be directly within the component on the record context based on the documentation -- or create the component programmatically inside another component
    – Jayant Das
    May 22, 2019 at 16:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.