Lightning Pages

While Salesforce releases new functionality three times a year, Lightning Components are becoming more an more important in Salesforce. In this post I want to give a quick overview of which kind of Lightning Pages we can create in Salesforce, and how do we have to design Lightning Components in order use them in such pages.

Lightning Pages are really FlexiPages, a metadata type that represents a customizable screen that can contain Lightning Components. Lightning Pages can be modelled in app builder or community builder, dragging & dropping existing components. However in some cases, there is no possibility yet of using such features and we have to use Metadata API or Tooling API to create them.

First of all, take a look at this schema, in which I have tried to capture all the possible Lightning Page types.

Let’s take a look at the FlexiPage metadata API documentation to see which types of FlexiPages (or Lightning Pages). Let’s divide them in groups:

First, we have:

• HomePage—used to override the Home page in Lightning Experience.
• RecordPage—used to override an object record page in Lightning Experience.
• AppPage—used as the home page for a custom app.

These three types of Lightning Pages can be modelled on App Builder.

If you create home or record pages, you will be able to easily assign them to different applications and/or profiles.

In the AppPage case, you will have to do some more steps, first create a Tab for the Lightning Page, and then embed it in a Salesforce1 or Lightning App navigation menu. Note that an AppPage can be used both in Salesforce1 and Lightning Experience, while Home or Record pages cannot.

Then, we have:

• CommRecordPage—used to override a record page in Lightning Experience, as created in the Community Builder, in Communities.
• CommAppPage— used to represent a custom page, as created in the Community Builder, in Communities.
• CommObjectPage—used to override an object page in Lightning Experience, as created in the Community Builder, in Communities.
• CommQuickActionCreatePage—used to override a create record page in Lightning Experience, as created in the Community Builder, in Communities.
• CommRelatedListPage—used to override a related list page in Lightning Experience, as created in the Community Builder, in Communities.
• CommSearchResultPage—used to override a search result page in Lightning Experience, as created in the Community Builder, in Communities.
• CommThemeLayoutPage—used to override a theme layout page in Lightning Experience, as created in the Community Builder, in Communities.

As you see, all these types of pages can be modelled on Community Builder. I am not going to explain the details of each type, but we will see how to configure Lightning Components to be used in these pages later.

Then, we have the next one:

• UtilityBar—used as the utility bar in Lightning Experience apps.

If you don’t know Utility Bar yet, check this post or read the implementation guide. Utility bar is a persistent horizontal footer that you can add to applications in Lightning Experience. The good news is that Lightning Components can be embedded there, as it is really a FlexiPage. Since Spring 17 Lightning Components can be added declaratively to Utility bar through App Manager.

And finally, we have

• MailAppAppPage—An email application pane used to override the default layout for Lightning for Outlook.

This page is used in Lightning for Outlook and Lightning for Gmail feature, that has been made Generally Available on summer 17. With this feature, you can drag-and-drop Lightning Components in the Email Application Pane for Lightning for Outlook and Lightning for Gmail.

If you want your Lightning Components to be ready to be part of these pages, your component should implement one of these interfaces:

• flexipage:availableForAllPageTypes— available for home, record, app pages and utility bar
• flexipage:availableForRecordHome— available for record pages
• forceCommunity:availableForAllPageTypes— available for all community pages
• clients:availableForMailAppAppPage— available for Mail App pages

Additionally, if you want your components to be sensitive to the context in which they are embedded, these two interfaces will be useful for you:

• force:hasRecordId— will expose the Id of the record for which the page is being rendered, as an attribute in the component (if it is a record page or community record page).
• force:hasSObjectName—will expose the sObject API name of the record for which the page is being rendered, as an attribute in the component (again, if it is a record page or community record page).