Sandboxes and Connected Orgs

Skuid pages and their resources can be packaged into static resources within Salesforce. This makes it easy to move your Skuid configuration from one org to another—for example, from your sandbox to a production org, or from one sandbox to a second one.


Whenever deploying, make sure to follow the change management process your company has established for moving, testing, and releasing changes from org to org.

Best Practices

Skuid recommends the following best practices for a successful deployment from Salesforce:

Change management

  • Create and adhere to a structured change management process for every deployment. Make sure all administrators are familiar with these protocols.
  • Always build and test new Skuid pages and apps in a sandbox org before deployment. This is a safe, easy way to customize your UX while avoiding the pitfalls of developing in a live production org.
  • Use targeted sandbox orgs for specific projects, or phases of projects (project development, project testing, etc.).
  • Before starting, map out your deployment, examining any expectations and assumptions that might create downstream problems.

Licensing and permission sets

  • When you spin off a sandbox from a production org, all end users and their permissions are mirrored in the sandbox. Salesforce sandbox orgs, however, do not have licensing limitations for managed packages (users assigned the right permission to interact with those packages, such as Skuid, maintain those permissions through assigned permission sets and profiles). The lack of a licensing limitation makes sandbox orgs a great place to show currently unlicensed and permissioned users the power and potential of installed packages.
  • Once you deploy Skuid from a sandbox to a production org, only users who have been assigned a Skuid license in the production org, with the appropriate permission sets, will have access to the Skuid implementation. This means you may need to add licenses and permission sets for users who are not provisioned in the production org. Any licensing limitations would apply in the production org.
  • If you would like to limit your Skuid licenses in a sandbox org to more accurately test your deployment, you can request this at Doing so allows you to assign and test licenses for a more realistic view of how your licensing assignments work within your configuration.
  • If you create a new end user in the sandbox, or change profiles or permission sets for existing end users in the sandbox, when you deploy to the target org, you will need to manually recreate these changes in the target org. Factor time to do this into your deployment schedule.

Sandbox Refreshes

A sandbox refresh re-copies your production environment into your current sandbox, overwriting potentially valuable information, including:

  • Any users created in the sandbox not provisioned in the production org.
  • All data created—including records within objects, which includes Skuid Pages—unless also they are manually created in the production org prior to refresh.
  • All metadata—any objects, fields, etc—unless also created manually or via deployment in the production org prior to refresh.


Salesforce customer levels offer different sandbox options, which govern which data can be copied into a sandbox and the frequency for sandbox refreshes. Refer to Salesforce documentation for information specific to your customer level.

To avoid accidental overwrites when refreshing a sandbox, you need to:

  • Create a new sandbox as a “holding” sandbox, where you will import page packs, design systems, and components, duplicate settings, and make sure everything works.
  • Refresh the original sandbox.
  • Move page packs, design systems, and components from the holding sandbox back into the original sandbox and re-configure settings.

To accomplish this, follow these steps:

  1. Create a new sandbox from a production environment or use an existing sandbox with Skuid installed.
  2. Build page packs for all Skuid pages and move them into the new sandbox.
  3. Build page packs for all Skuid page assignments and move them into the new sandbox.
  4. Export all custom design systems and move them into the new sandbox.
  5. Create component packs for all custom Skuid components and move them as static resources into the new sandbox.


Page packs, design systems, and component packs are all stored as static resources. Ensure these static resources are properly downloaded and uploaded to the new sandbox.

  1. Copy or screenshot all external data source and authentication provider settings, and recreate them in the new sandbox.


Client ID and Client Secret settings will be masked, so this information needs to be retrieved again when creating the new sandbox.

  1. Ensure all pages are working properly before refreshing the sandbox.
  2. Move all pages, design systems, and component packs into the refreshed sandbox.
  3. Recreate data source settings in the refreshed sandbox.

The Deployment Process

In contrast to sandbox refreshes, full deployments to connected orgs are a more involved process. You’ll be completing three separate processes utilizing Skuid’s export and import capabilities, Salesforce’s change sets feature, and (optionally) the skuid-sfdx Salesforce CLI plugin.


You must execute these processes in this order:

  1. Packaging your Skuid resources and other configurations as static resources
  2. Pushing those static resources and other necessary salesforce components from your sandbox org to your destination org using as an Outbound Change Set
  3. Deploying or unpacking your Skuid pages, as well as unpacking your page assignments

If you have a custom design system with your Skuid configuration, you’ll be exporting and importing that as well.

Once all of your resources are in your destination org, you must ensure you set your page overrides accordingly.

Package your resources from your source org

Step 1 (Optional): Group your pages inside a module [[]]

If you need to separate the pages you are deploying from other Skuid pages, you can organize them into a module. Otherwise, proceed directly to Step 2.

Step 2: Create a page pack or pull pages with skuid-sfdx [[]]

When moving pages from one org to another, there are two primary options:

  • Bundling pages into page packs (Slower, but declarative)
  • Using the skuid-sfdx to pull and push pages (Faster, but programmatic)
Bundling pages into page packs [[]]

Page packs provide a declarative option for moving your resources to a connected org. To do so, you’ll create a static resource containing your pages:

If you’ve grouped your pages into a module

See using modules to build page packs.

If you have NOT grouped your pages in a module

See creating a page pack.

Pull and push with skuid-sfdx (Advanced) [[]]

The skuid-sfdx Salesforce CLI plugin provides a way to pull and push Skuid pages without the use of page packs. While it does involve use of the command line, it is a far faster deployment option, and recommended over the use of page packs for experienced builders with larger deployment needs. If you would like to use this deployment tool, read its basic usage and installation instructions in the skuid-sfdx topic.


The example commands below assume you are using a macOS or Linux operating system and have some familiarity with how the CLI works.

  1. If you haven’t already, authenticate to the org you’ll be pulling from..

  2. Navigate to, or create, a directory on your local machine to store your Skuid pages by entering one of the following commands:

    # Navigate to an existing directory
    cd path/to/my/skuid-page-directory
    # And/or create a new directory
    mkdir new-directory
    cd new-directory
  3. Pull the Skuid pages to your local machine:

    # Pull all pages in the source org
    sfdx skuid:page:pull
    # Or if you've organized your pages in a specific module
    sfdx skuid:page:pull --module CommunityPages

Step 3 (If applicable): Package your page assignments [[]]


If you utilize page assignments in your sandbox, these will not be packaged with your Skuid pages. Instead, you must package them as a separate external resource, and push that using a change set. (Thankfully, this is an easy process!)

In Skuid

  1. Click Deploy.
  2. Select the page assignments relevant to your deployment:
    • If using only a selection of your page assignments:
      • Select your relevant page assignments, and the Mass Update Selected Rows button will appear.
      • Click the down arrow and select Package Selected Page Assignments.
      • Enter an appropriate name and description for your static resource.
      • Click Build Page Assignment Pack.
    • If using all of your page assignments:
      • Click the down arrow beside Add new Page Assignments, and select Package all Page Assignments.
      • In the Packaging Options tab, keep the default “All” and “Include All” selections.
      • In the Choose Pack tab, give the page assignments a name and description that make sense for your deployment.
      • Click Package all Page Assignments.

You now have a static resource, with a name you will remember as you move through the next stages of deployment.

Step 4 (If applicable): Export your design system [[]]

In Skuid

  1. Click Design Systems in the navigation bar of the Skuid UI.
  2. Locate the design system in the list and click the dots-vertical More Options icon beside it.
  3. Click Download as file.
  4. Save the compressed design system file to a location you can find on your computer.

Push Skuid resources to your destination org

In this step, you’ll be using an Outbound Change Set. Change sets are a useful way to push a variety of resources and metadata from one Salesforce org to another. In this case, you’ll be pushing the static resources containing your Skuid pages and (if applicable) your page assignments.


Take special care when configuring standard objects and standards fields, particularly picklist values. These changes cannot be included in a change set, and must instead be manually reproduced on target orgs.

Step 1: Create a new outbound change set [[]]

In Salesforce

  1. Navigate to or quick search for Deploy> Outbound Change Sets.
  2. Click New.
  1. Give the package a name and description that clearly identifies your change set and explains the change set’s purpose.
  2. Click Save.

Step 2: Select the Change Set Components you created for deployment [[]]

  1. In the Change Set Components area, click Add.
  2. Individually add the following components to your change set:
    • Static Resources:
      • If applicable, the “Pages” static resource
      • The “Page Assignments” static resource you created in Package Your Resources (above)
      • Any custom JavaScript or CSS files used within your Skuid implementation
    • Visualforce pages
      • Click component type and select Visualforce Page
    • Custom objects, configurations, and any automation settings
  1. Click Add To Change Set.


Which resources you’ll need to include will depend on if this is your first deployment or not:

  • If this is your first deployment to a new org, you must include all of your newly created resources in addition to your Skuid pages; this includes images, Visualforce pages for use with overrides, JavaScript code, as well as page-level CSS.
  • If you are deploying to an org that already contains most of your foundational resources, then you must include any resources that have been updated since your last deployment, which can include static resources containing CSS, JavaScript, and image files—all in addition to your Skuid pages

Step 3: Upload your resources to your target org [[]]

  1. In the Change Set Detail pane, click Upload.
  1. On the next screen, choose your Target Organization and click Upload again. This target org can be your production org, or (depending upon your company’s change management process) another sandbox org, such as a Quality Assurance sandbox.


Some Visualforce pages that are built in the sandbox may be on a newer API version than what is in the destination org. These will have to be manually copied and pasted.

Step 4: (If applicable) Deploy your Skuid pages with skuid-sfdx [[]]

If you utilized skuid-sfdx to pull your pages locally, you may now deploy them to the destination org.

  1. Optional, but for ease of use, switch the default org for sfdx <>`__.

  2. Push the Skuid pages to the target org.

    # Pull all pages in the source org
    sfdx skuid:page:push
    # Or if you've organized your pages in a specific directory, wildcards allowed
    sfdx skuid:page:push --dir skuidpages/*CommunityPages
    # Or, if you *did not* change your org above, the skuid-sfdx plugin allows you
    # to indicate a different target org, assuming you've authenticated before
    sfdx skuid:page:pull --targetusername [email protected] --dir skuidpages/*CommunityPages

Unpack the Skuid resources inside your destination org

Step 1: Deploy your inbound change set within your destination org [[]]

Now that you’ve uploaded your change set to your destination org, it is now an inbound change set awaiting deployment within that destination org. After Salesforce processes that change set, you must deploy that inbound change set before you can use the resources within it.

In Salesforce


It may take up to 30 minutes before your inbound change set is available for deployment.

  1. Navigate to Deploy>Inbound Change Sets.
  2. Under Change Sets Awaiting Deployment, click the change set you uploaded to this connected org.
  3. (Optional) If you wish to preview the deployment results for this change set, click Validate under the View Details pane.
  4. Click Deploy under the View Details pane.
  5. You may be prompted to choose a Test Option for your deployment. If so, choose an option appropriate for your use case.
  6. Salesforce will display a final warning regarding overwriting components and deployment failure; click OK.

After this your deployment will begin. Depending on the size of your deployment, the components within it may not be instantly available. You can see the progress of your deployment under Deploy>Deployment Status.

Step 2 (Optional): Recreate your module [[]]

If your pages are grouped using a module, you must recreate your module in your destination org so that the page grouping is retained when the pages are unpacked. Simply follow the steps for the target org as outlined in Group your pages inside a module.

Step 3: (If applicable) Unpack your Skuid pages [[]]


If you used the skuid-sfdx plugin to push your pages, you may skip this section.

Now that your module is created, and your static resources have been pushed into your destination org, you can actually unpack the Skuid page pack.

In Skuid

See unpacking page packs.

Once the pages are unpacked, you can use the Module filter to see the list of pages that you just added.


Importing page packs into an org with Skuid pages that match in both module and page name will overwrite those pages and create a new page revision, even if the page has not changed.

No worries, as all of your past page data will remain intact, but it is wise to keep this behavior in mind as you move your resources from org to org.

Step 4 (If applicable): Unpack your page assignments [[]]

  1. Click Deploy in the Skuid navigation bar.
  2. Click the down arrow beside Add New Page Assignment and select Unpack Page Assignments from Pack(s).
  3. Click the checkbox beside your page assignment static resource.
  4. Click Unpack.

Step 5 (If applicable): Import your design system [[]]

  1. Click Design Systems in the navigation bar of the Skuid UI.
  2. Click the dots-vertical More Options icon above the list of design systems.
  3. Click Import.
  4. Click Upload and navigate to the appropriate design system file—look for the .designsystem extension. Alternatively, drag the file into the upload modal.
  5. If necessary, Confirm your selection.


If you already have a design system of the same name, Skuid asks if you wish to override the design system static resource.


If this is the first time you’ve imported the design system, you must make sure that the imported design system’s name EXACTLY matches what is in the original sandbox org, or it will not work.

Step 6: Override list/view actions to redirect to your Skuid pages [[]]

Now that all of your Skuid pages (and other resources) are inside your destination org, make sure your overrides work as expected. You’ll need to ensure overrides set at the Object level in your sandbox match those in your target org.

In Salesforce

Locate the objects that have actions you want to override and check that the configuration of the Buttons, Links, and Actions in your target org matches the configuration of those elements in your sandbox org.

For more on how to do this, read Overriding your Salesforce UI with Skuid.


Each end user must have a valid subscription and the proper user permissions to access Skuid pages and resources.

Step 7: User Level Maintenance [[]]

The final step to unpacking your skuid resources inside your destination is making all necessary user-level updates. This includes:

  • Ensuring that end users who will access the Skuid pages have the appropriate Skuid licensing and permission sets
  • Manually updating Salesforce profiles and permission sets, as needed
  • Assigning static resources and components

You also need to give specific profiles access to the necessary Visualforce pages:

In Salesforce

  1. In Setup/Develop/Visualforce Pages, locate the page you want to give access to.
  2. Next to the page name, click Security.
  3. In the Enable Profile Access page, select from the Available Profiles on the left side and add to the Enabled Profiles on the right side using the Add arrow.

Additional Notes

  • In Salesforce, Skuid pages and page assignments are, by default, set as private. Unless you changed this setting when you were building and testing pages in the sandbox org, deployed pages and page assignments will need to be made public.
  • More complex configuration items within Skuid—such as data sources, component packs, auto-assignment rules, and others—must be reconfigured manually in the target org. If you utilize these features, thoroughly test your page’s functionality in the target org to be sure that they are working properly.
  • If you use a principal page for your deployed pages, ensure that the principal page is included in the page pack that you move using a change set. Failure to do so may result in broken dependent pages in the target org.
  • While this process will work when deploying Skuid from a sandbox to that sandbox’s connected org, change sets will not work when deploying to entirely separate orgs. For these types of deployments, you must use the Migration Tool and Apache’s Ant build tool.