Salesforce Lightning

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.


When building Lightning pages in Salesforce’s Lightning App Builder, do not mix the API versions of your Skuid pages.

If one Skuid Page (Aura) Lightning component displays an API v2 page, all other Skuid Page (Aura) Lightning components must also display v2 pages. If using v1 pages, then all pages must be v1.

Mixing different API versions within one Lightning page will result in unexpected behaviors.

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.

  • It is not possible to disable Lightning Experience keyboard shortcuts, such as pressing e to begin editing a record in a modal. This can sometimes cause issues for certain field types like picklists.

    For any picklist field experiencing this issue, consider displaying the field as a combobox. This renderer type functions as a text input and does not trigger most keyboard shortcuts.

  • 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 that all pages should use the same design system and CSS. Otherwise your theming may appear inconsistent, or the CSS rules from one Skuid page may override the rules for others.


OAuth authentication currently does not work within the Skuid Page (Aura) Lightning component. If using data sources while working within Lightning Experience, consider one of the following alternatives:

General best practices

While implementation and design details can vary from deployment to deployment, there are some general best practices when building pages for a Lightning deployment:

The Skuid Page (Aura) Lightning component

The declarative and primary way to deploy Skuid pages is via the Skuid Page (Aura) 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 (Aura) Lightning component as long as model conditions look for the id property as they normally would.

Properties [[]]

Wherever a Skuid Page (Aura) 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.

You may also control this component’s visibility within the Lightning page through Salesforce’s component visibility properties.

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 (Aura) 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.

Within Lightning Quick Actions

Skuid pages can be used as custom quick actions, but there are two caveats:

With these caveats in mind, admins must take some additional steps to use Skuid as a quick action:

  1. Create the custom Lightning component.
  2. Make the quick action accessible as global quick action.
  3. Add the quick action to the global layout.


  • Because quick actions can occur anywhere within a Lightning app, it is important to realize that Skuid pages used within them may interact with data across the app regardless of context. Because of this, make heavy use of event publishing to ensure that other Skuid pages and Lightning components are aware of any data updates made within the quick action.
  • If you would like to create an object-specific quick action, complete the steps below while referring to the Salesforce Trailhead unit on the topic.

Create the custom Lightning component

To expedite the process of creating a quick action, select the option when creating the custom Lightning component.

  1. Click the Setup gear.
  2. Click the Developer Console.
  3. In the Developer Console’s new window, click File > New > Lightning Component.
  4. Under Component Configuration, click Lightning Quick Action.

From there, finish creating the component as normal.

Make the quick action accessible

With the custom Lightning component created and marked with the appropriate quick action interface, the global action must now be made accessible.

Within Salesforce Setup:

  1. Navigate to User Interface > Global Actions > Global Actions.
  2. Click New Action.
  3. Set the quick action’s properties:
    • Action Type: Lightning Component
    • Lightning Component: Select your custom Lightning component.
      • Set the height, label, and name as appropriate.
  4. Click Save.

Add the quick action to the global layout

With the quick action itself now accessible, add it to the global publisher layout so it is visible to end users.

Within Salesforce Setup:

  1. Navigate to User Interface > Global Actions > Publisher Layouts.
  2. Click Edit beside Global Layout.
  3. In the Global Layout Pane, click Mobile & Lightning Actions.
  4. Drag and drop the quick action you created into the Mobile & Lightning Experience Actions section within the Global Publisher pane.
  5. Click Save.

The Skuid Page Assignment Lightning component

While the Skuid Page (Aura) Lightning component is the primary method of including Skuid pages within a Lightning page, you need to use the Skuid Page Assignment Lightning component to display different Skuid pages in different situations.

This component is found under the Custom - Managed header wherever Lightning components may be used, such as the Lightning App Builder.

This is typically the recommended deployment method within Lightning-enabled orgs in which page assignments are frequently used. It allows the use of Skuid page assignments within the same Salesforce page as other Lightning components.

For example, you have a sales dashboard in Lightning and you want specific Skuid pages to appear based on user profile. You would use the Page Assignment Lightning component to render the appropriate Skuid view according to the user profile viewing the Lightning page.


  • Situation Name: The exact situation name of the Skuid page assignment you wish to use.

You may also control this component’s visibility within the Lightning page through Salesforce’s component visibility properties.

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.

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-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-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. Beside Lightning Experience Override field, click Lightning Component Bundle.
  8. In the Lightning component 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 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"/>

Standalone Lightning Applications

For more advanced builders, it’s also possible to utilize Skuid within a standalone Lightning application.

If you choose do this, include extends="force:slds" in your markup, otherwise you may experience unexpected behaviors in your Skuid pages:

<aura:application extends="force:slds">
  <skuid:page name="Insert-Your-Skuid-Page" />


This is not required when creating Lightning components or pages, and using this markup in those scenarios will result in a compiler error.


Visualforce overrides

Whether you’ve used the Redirect method or the skuid:page Visualforce component, your Visualforce 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 end users to see default Lightning pages—consider using Skuid page assignments in conjunction with Lightning page assignments

Visualforce Page Lightning component

It is also possible to embed Visualforce pages within Lightning pages using the Visualforce Page Lightning component. However, doing so does require some preparation:

After these steps have been completed, your Visualforce page is ready to use.

Within the Lightning App Builder, drag and drop the Visualforce Page Lightning component onto the page, and then update the Visualforce Page Name property in order to select the appropriate Visualforce page.

Salesforce Mobile

To use a Skuid page within a Salesforce mobile (previously Salesforce1) context, you must create a Lightning Page tab containing your Skuid page. That tab then must be added to the Salesforce mobile navigation list.

  1. From the Salesforce sidebar, navigate to Mobile Administration > Salesforce Navigation (Classic) or Apps > Mobile Apps > Salesforce Navigation (Lightning Experience).

  2. Select the appropriate Lightning Page tab in the Available pane.

  3. Click the Add arrow.


    You can also re-order your navigation menu items using the Up and Down arrows.

  4. When you are satisfied with your navigation menu settings, press Save.

It is also possible to deploy Skuid pages to Salesforce mobile using a Visualforce tab.

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 (Aura) Lightning component within the Lightning App Builder—the deployment method recommended to take full advantage of future updates and org support from Salesforce.

Skuid SFX is LockerService compliant. Skuid deployments that take advantage of the Skuid Page (Aura) 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.

Debugging in Lightning Experience


This information only applies when a Skuid page is deployed through either the Skuid Page (Aura) or Skuid Page Assignment Lightning components. It does not apply to the Skuid Page (LWC) component.

While testing pages within Lightning Experience, it can be difficult to employ more advanced methods of debugging using the Skuid JavaScript API because the skuid object is inaccessible.

To access the skuid JavaScript object within a Lightning page at runtime:

  1. Execute the following in your browser’s console:

  2. Right click the ellipsis {...} returned by this command.

  3. Click Store as a global variable.
  4. (Optional) Enter the following in the console:

    var skuid = temp1;


    You may skip this step, but you’ll need to use the temp variable in place of skuid to access JavaScript APIs.

    If you have stored other global variables in this manner, you’ll need to set skuid to equal whichever temp variable is created by this process, e.g. temp2, temp3, etc.

After doing so, you’ll be able to freely use the skuid object and all of its assorted APIs within the page.


When working with API v2 pages, you still must set a skuid.runtime context using the variable accessed above. See the Sandboxing section of our API reference for more information.


This is intended exclusively for debugging purposes, not to be included with production code. Including this command in production code will have no effect.