Salesforce Lightning

A major update to the Salesforce experience, Lightning is a brand name encapsulating a broad range of platform enhancements:

Using Lightning—and all of its elements—in conjunction with Skuid can dramatically enhance your UX. You can have a mixture of Lightning pages (built within the Lightning App Builder) and Skuid pages throughout your org! You can also incorporate entire Skuid pages inside of Lightning pages, allowing you to use the power of Skuid’s multi-object, component-based goodness alongside the awesome new tools that come with Lightning Experience.

Heads up

  • To use any of the Lightning components listed below, you must first configure My Domain for your org. All Lightning components require that My Domain be enabled.
  • You cannot disable the Lightning header within Lightning Experience, so keep this in mind when designing Skuid pages, especially when using headers within those pages.
  • If you are using multiple Skuid pages within the Lightning page—whether by using several Skuid Page components, several custom Lightning components, or any combination of the two, keep in mind:
    • Unless all model IDs across pages are unique, one Skuid page may attempt to access and write to another’s model.
    • All pages should use the same theme and CSS. Otherwise your theming may appear inconsistent, or the CSS rules from one Skuid page may override the rules for others.

The Skuid Page Lightning component

The declarative and primary way to deploy Skuid pages is via the Skuid Page Lightning component. This Lightning component is labeled Skuid Page, and can be found under the Custom - Managed header wherever Lightning components may be used, such as the Lightning App Builder.

This is the recommended deployment method within Lightning-enabled orgs, as it allows the use of Skuid pages within the same Salesforce page as other Lightning components.


Creating a record detail page? No extra properties here are needed on the Skuid Page Lightning component as long as model conditions look for the id property as they normally would.


Skuid pages using in-line resources will not load in LockerService-enabled orgs using this deployment method until accompanying page support files are generated. To do so, navigate to Skuid’s Configure > Org Preferences > Page Support Files tab. (For more information, see the In-line resources and page support files section of the Skuid Developer Guide.)

Properties [[]]

Wherever a Skuid Page Lightning component is used, the following properties are configurable. These properties determine which Skuid page will be displayed and how it receives its data.

For most use cases, only the Page Name and Page Type properties are necessary.

  • Page Name (required): Enter the exact Page Name field of the Skuid page you wish to use.

  • Page Type (required): Select whether the Skuid page was built in the Desktop App Composer or the Skuid Mobile Builder.

  • Id (optional): A shortcut to inserting a specific ID as a page parameter. This property is typically reserved for very particular use cases that involve object IDs and model conditions.

    For example, a model for the Account object has a model condition that looks for the id Page/URL parameter value. When the Skuid page loads within the Lightning App, the Skuid model will recognize and apply the value listed within this property.


    Equivalent to placing {"id":"id-value-here"} in the Page Parameters property below.


    You do not need to use this property for Lightning record detail pages. Instead, ensure that any detail components look for the id page parameter—which is always passed into Lightning record detail pages.

  • Page Parameters (optional): A field for passing additional parameters into the page by entering a JSON string—{"parameter":"value","parameter2":"value2"}—containing those parameters.

    For example, entering {"industry":"Apparel"} in this property would insert that value as a page parameter that model conditions may use. A Skuid page with a model for the Account object, which itself has a model condition for the industry Page/URL parameter value, would then only display accounts within the Apparel industry.

  • Add URL parameters to Page Parameters (advanced): If you have set certain Action Framework actions or JavaScript Snippets to look for URL parameters within the Skuid page—or if an Action Framework item redirects users to a URL with URL parameters—check this box to make those parameters accessible as page parameters.


    Ensure that any URL parameters are in the correct section of the URL, otherwise they will not be available as page parameters. This is especially important within Lightning Experience apps, where URL parameters must come between and the Lightning page (which is denoted by a hash (#) symbol).

    Note the position of ?parameter=value in the examples below.



Within the Lightning App Builder

The Lightning App Builder lets you drag and drop Lightning components into any section within the page’s chosen template—meaning you can drag one or more Skuid pages anywhere you’d like within that template.

  1. Open or create a page within the Lightning App Builder.
  2. From the Lightning Components sidebar, click and drag the Skuid Page component into a component region inside your page.
  3. Fill out the appropriate properties.
  4. Once Skuid Page component has been configured appropriately, click Refresh to load a preview of the Skuid page within the App Builder.
  5. When satisfied, click Save.
  6. To deploy the Lightning page, click Activate. For more information on activating pages, see Salesforce documentation.

Within the Utility Bar

The utility bar allows for easy access to quick and useful tools within Salesforce apps, and the Skuid Page Lightning component can be added as a utility bar item.

In Salesforce Setup:

  1. Click Apps > App Manager.
  2. Beside the appropriate app, such as Sales, click fa-caret-down > Edit.
  3. Click the Utility Bar tab.
  4. Beside Utility Bar Items, click Add.
  5. Click the Skuid Page component.
  6. Fill out the Skuid Page component’s properties.
  7. Click Save.


Keep in mind that the utility bar is persistent and does not necessarily refresh. Therefore, Skuid pages will not automatically react to actions that take place outside of the page. If a new record is created or updated within a Lightning page—even if the utility bar is open—the Skuid page’s models must be requeried to accurately reflect the data.

Because of this, it is generally best practice to use Skuid pages focused on surfacing data appropriate for a particular context—such as a contact phonebook on an opportunity page—rather than on data that will need to be being changed or updated within the utility bar.

If data within a utility bar Skuid page must be kept up-to-date, consider adding a button to requery any necessary models.

Lightning Component Bundle Overrides

Aura is the open source, UI framework used to develop numerous other frameworks and features that make up Salesforce Lightning. Using this markup, you can also create your own custom Lightning components—and embed Skuid pages within them. This is the best Lightning-based deployment method to use if you want to override several standard actions on objects—View, Edit, New, and Tab—with Skuid pages.

The steps below—an abbreviated walkthough—create a basic Lightning component and use it to override an object’s standard action. This information allows a team’s citizen developers to get started with Lightning components and Skuid. For more information, see Salesforce’s Override Standard Actions with Lightning Components.

If you have a more advanced use case, you may need to utilize different Lightning component interfaces within your Aura markup. These interfaces determine how your component bundle may be used, and they should be the first things to check if you are running into issues. For more in-depth information, see Salesforce’s What is the Lightning Component Framework?


The process for overriding Lightning pages using Lightning component bundles is very similar to using Visualforce overrides to deploy Skuid pages, requiring a small amount of markup and then an override to be set. While Lightning component bundles are the recommended deployment method if an org is entirely Lightning-based, Lightning component bundle overrides will not appear for Salesforce Classic users within the org. Instead, users will be redirected to standard Salesforce layouts in Classic.

Because of this, this Lightning override method is not recommended for orgs that have some users in Salesforce Classic and others in Salesforce Lightning. Instead, consider continued use of Visualforce overrides.


Skuid pages using in-line resources will not load in LockerService-enabled orgs using this deployment method until accompanying page support files are generated. To do so, navigate to Skuid’s Configure > Org Preferences > Page Support Files tab. (For more information, see the In-line resources and page support files section of the Skuid Developer Guide.)

Creating the Lightning Component Bundle

There are two key parts to creating this Lightning component bundle:

  • The lightning:actionOverride implementation, which signifies the component can be used for such overriding standard actions.
  • The Skuid page itself, embedded with the skuid:page markup.

In Salesforce Lightning Experience:

  1. Click the Setup gear.

  2. Click Developer Console.

  3. In Developer Console’s new window, click File > New > Lightning Component.

  4. Enter an appropriate name, such as SkuidOpportunityTab.

  5. Enter a description for the Lightning component.

  6. Click Submit

  7. Within the workspace, copy and paste the appropriate Aura markup, replacing Insert-Skuid-Page with the appropriate Skuid page name. Detail/record pages require some extra markup to receive the record ID parameter.

    • For list/tab pages:

       <aura:component implements="lightning:actionOverride,force:appHostable" access="global">
          <skuid:page page="Insert-Your-Skuid-Page"/>
    • For detail/record pages, you’ll need to include the force:hasRecordId interface as well as id="{!v.recordId}" within the skuid:page component:

      <aura:component implements="force:hasRecordId, flexipage:availableForRecordHome" access="global">
        <skuid:page page="Insert-Your-Skuid-Page" id="{!v.recordId}"/>
  8. Click File > Save.

A new Lightning component bundle is created, and the component’s markup has been edited to display the designated Skuid page.

Applying the override

Now that the component bundle has been created, set it as the override for the Salesforce object’s action.

  1. Click the Setup gear.
  2. Click Setup.
  3. Click Object Manager in the Setup page navbar.
  4. Click the object to edit, such as Opportunity.
  5. Click Buttons, Links, and Actions.
  6. Beside the appropriate action, such as Tab, click fa-caret-down > Edit.
  7. For the Override With field, click Lightning Component Bundle.
  8. In the Lightning Component Bundle picklist, select the Lightning component you created in the previous section.
  9. Click Save.

With this override in place, the designated Skuid page will display for all Lightning-enabled users within the org when they trigger the overridden action.


  • If the Skuid page does not render when visiting the appropriate Salesforce object action, and it contains in-line resources, check that a page support file has been generated for the Skuid page.

  • If models are not receiving all of their data, or are receiving other errors, add the hasSObjectName interface to the Aura markup:

    <aura:component implements="lightning:actionOverride,force:hasSObjectName,force:appHostable">
       <skuid:page page="Insert-Your-Skuid-Page"/>

Visualforce overrides

If you have already overridden your Salesforce UI using Visualforce pages, good news—your overrides will still function properly! You can pick and choose which Skuid pages you want to use for which Salesforce standard actions (View, New, Edit, Tab, List, etc.), while utilizing your Lightning enhanced pages for other actions.

If you wish to use a Skuid page as a component inside of a Lightning page—alongside other Lightning components—then this is not the method you’ll want to use. While there may be exceptions, Visualforce overrides should generally be seen as a way to substitute entire Skuid pages for specific Salesforce actions.


Lightning Experience will preserve Visualforce overrides—even page assignments. However, the Use Standard Layouts option does not work in Lightning Experience.

If you are seeing issues with your Skuid page assignments—and require some users to see default Lightning pages—consider using Skuid page assignments in conjunction with Lightning page assignments

LockerService Support


These changes do not yet affect deployments that make use of Visualforce overrides, which are preserved in Lightning Experience and currently function as they have in the past.

The information below applies to Lightning deployments accomplished through the Skuid Page Lightning component within the Lightning App Builder—the deployment method recommended to take full advantage of future updates and org support from Salesforce.

Skuid on Salesforce is LockerService compliant. Skuid deployments that take advantage of the Skuid Page Lightning component will see fully functional declarative features—including in-line resources—within the Lightning framework. Because of this, Skuid deployments can move forward as your org transitions to Salesforce’s Lightning Experience.

A lot of effort has gone into streamlining and updating Skuid’s inner workings to ensure compliance, while also retaining a consistent experience. While most of these changes have occurred on Skuid’s backend, there are some admin-facing changes you should be aware of.


Currently, the Skuid Chatter component does not function within Lightning Experience. Consider using the Chatter or Chatter feed Lightning components alongside a Skuid Page Lightning component instead.

In-line resources and page support files

As an admin, you can still add and edit in-line resources in the App Composer, but to remain LockerService compliant, Skuid now stores all in-line resources within page support files.

For more information, see the In-line resources and page support files section.