Lightning Pages and managed packages

Lightning Pages are a concept introduced by Salesforce to allow creating and customizing pages in Salesforce with simple drag & drop, for Lightning Experience and Salesforce1. In this post I want to explain how these pages behave in a managed package environment.

Lightning Pages

As of Summer 18 there are three types of pages that can be created:

• Home Pages – to override an org home page
• Record Pages – to override the record view / edit / new pages
• App Pages – to be accessed by tab (or url)

These are a kind of advanced layouts, that are created and customized in Lightning App builder, and that as almost everything is Salesforce, has an equivalent metadata type, which is FlexiPage. This means that the XML code that represents a Lightning Page that has been created in app builder can be retrieved (for example using workbench or the metadata API directly) and stored in your favorite version control system, or in the other way around, the code can be deployed so that a Lightning Page is created in your org. Beware Lightning Pages are different from standard or classic layouts, which metadata type was Layout.

Lightning pages are packageable and not subscriber editable.

Lightning Pages assignments

In the case of however, we have several options for pages activation (assignment) in the customer org:

Home pages:

• Assign as org default
• Assign by profiles

Record pages:

• Assign as org default
• Assign as app default
• Assign as app default, by record type and profile

App pages:

• Assign to sys admin only
• Assign to all users

You can see the assignments that exist in an org in several places, either from setup –> lightning app builder –> page detail:

Or, if it is a record page, through setup –> object managers –> object –> lightning record pages:

Package org level assignments for Lightning Record Pages are stored as action overrides, in the object definition. This is not upgradeable, as customer overrides are respected for custom objects. Example:

<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
    <actionOverrides>
        <actionName>View</actionName>
        <comment>Action override created by Lightning App Builder during activation.</comment>
        <content>testRecordPageByOrg</content>
        <formFactor>Large</formFactor>
        <skipRecordTypeSelect>false</skipRecordTypeSelect>
        <type>Flexipage</type>
  </actionOverrides>
</CustomObject>

However, app level assignments for Lightning Record Pages, is stored in the CustomApp metadata, as action overrides too. These are upgradeable:

<CustomApplication xmlns="http://soap.sforce.com/2006/04/metadata">
    <actionOverrides>
        <actionName>View</actionName>
        <comment>Action override created by Lightning App Builder during activation.</comment>
        <content>testRecordPageByApp</content>
        <formFactor>Large</formFactor>
        <skipRecordTypeSelect>false</skipRecordTypeSelect>
        <type>Flexipage</type>
        <pageOrSobjectType>Test__c</pageOrSobjectType>
    </actionOverrides>
</CustomApplication>

If you package Lightning Record Pages assigned to an app that you are distributing via a managed package, any custom assignment that the end user may have done will be prevail.

This is, if the customer has any assignments defined for an app or app, record type and profile, these will take precedence over our packaged assignments. If users don’t have any assignments, our packaged lightning record pages will be used, and the good news is that any changes that we perform to those pages will be applied in subsequent upgrades, as they are not subscriber editable.

In addition, if in a future package we package a new Lightning Record Page and assign it to an app, for example, this one will take precedence over the previous packaged one.

But what about app, record type and profile level assignments for Lightning Record Pages? This is stored at CustomApp level, using a new metadata type called profile action overrides:

<CustomApplication xmlns="http://soap.sforce.com/2006/04/metadata">
    <profileActionOverrides>
        <actionName>View</actionName>
        <content>testRecordPageByApp</content>
        <formFactor>Large</formFactor>
        <pageOrSobjectType>Test__c</pageOrSobjectType>
        <type>Flexipage</type>
        <profile>Admin</profile>
    </profileActionOverrides>
    <uiType>Lightning</uiType>
    <utilityBar>TestApp_UtilityBar</utilityBar>
</CustomApplication>

According to the docs, these are not supported in packaging.

Record Detail component & Page Layouts

It is worth to mention that standard layouts can be used in a Lightning Page (for a record page), using the “Record Detail” component, but don’t have to be there specifically. If you edit a standard layout (eg: add new fields, change sections…) with the classic page layout editor, these changes will be reflected in the record detail component too, and thus in your Lightning Page (bear in mind the layout must be assigned to the object/profile/record type).

As, in contrast to Lightning Pages, Page Layouts are not upgradeable, if you want that a Page Layout change is reflected in the customer org (and thus in the “Record Detail” component), you will need to do it either manually or program a post-installation step that performs this change (typically using Metadata API).