Skip to main content
Labs feature. Deployments depend on Environments, which is marked with the Labs badge in the Elementum UI because the feature is still being validated. Behavior, scope, and availability may change before the feature reaches General Availability, and not all Elementum customers have access yet. See Upcoming Features for what the Labs tag means.
Deployment copies an app and its configuration from a source environment to a target environment. Before deploying, make sure both environments exist and have CloudLink configured. See Understand and Configure Environments for the prerequisites.
Required Permission: You must hold the DEPLOY_APPS permission for the target environment to deploy an app to it. See Who can deploy below.

​
How deployment works

You can deploy in any direction: from a non-production environment to Production, from Production into another environment to test changes, or between non-production environments. What is included in a deployment Automations; record layouts, related views, and form builder configuration; Flow definitions; approval processes; assignment rules; and report and analytics configuration for that app. The deployment is tracked with status and history on the app’s Deployments page.

​
Who can deploy

Promotion to each environment is gated by the DEPLOY_APPS permission for that environment. Edit or admin rights on an app no longer imply the right to deploy it; users must hold DEPLOY_APPS in the target environment to push an app there.
BehaviorWhat it means
Per-environmentDEPLOY_APPS is granted independently in each environment. A user with DEPLOY_APPS in Staging cannot promote to Production unless they also hold it in Production.
Decoupled from app edit rightsGranting someone the ability to update an app’s configuration does not give them the ability to promote that app. Configure who can build apps and who can release them as separate decisions.
Granted through rolesAdmins assign DEPLOY_APPS through a role (managed or custom) in the target environment. Role membership is environment-specific — see Environment-specific role membership.
A user typically needs DEPLOY_APPS in every environment they release to. For a Dev → Stage → Prod pipeline, the same release engineer commonly holds DEPLOY_APPS in both Stage and Prod, while developers hold it only in Dev.

​
Initial vs. subsequent deployments

The first time you deploy an app to a target environment, settings are copied from the source. On later deployments to the same target, most configuration is updated to match the source, but the following destination values are left as you set them in that environment:
ConfigurationInitial deploymentLater deployments
AI Search target lagCopied from sourceTarget environment’s value is kept
Access policiesCopied from sourceTarget environment’s policies are kept
After the first deployment, you can set AI Search target lag and access policies per environment; later deployments will not overwrite those choices.

​
Deploy an app

1

Navigate to the App

Open the Apps icon app you want to deploy in its source environment (the environment where the app currently exists).For example, to deploy an app from Development to Production, open the app in the Development environment.
2

Open Deployments

In the app’s left navigation, under the Configuration section, click Deployments.The Deployments page shows all available environments with their deployment status.
3

View Environment Status

Each environment is displayed as a card showing:
  • Environment name and description
  • Status indicator: Deployed (green), Deploying (yellow), Failed (red), or Not Deployed (gray)
  • Deploy button to initiate deployment
The right panel shows Deployment History. For what each record includes, see Deployment history below.
4

Initiate Deployment

Find the target environment (where you want to deploy the app) and click the Deploy button on its card.A confirmation modal appears:
  • Title: “Deploy App To Environment”
  • Message: “Deployment will copy all app configurations and associated objects to the target environment.”
  • Visual showing the deployment flow from source to target
  • Summary: “Deploy App from [Source] to [Target]”
5

Confirm and Deploy

Review the deployment details and click Deploy to proceed.The deployment process begins:
  • Status changes to “Deploying” (yellow)
  • Progress bar shows deployment progress
  • Upon completion, status changes to “Deployed” (green)
Initial vs. subsequent deployments behave differently for some settings (for example AI Search target lag and Access Policies). See Initial vs. subsequent deployments.
6

Monitor Deployment

Track deployment progress:
StatusDescription
DeployingDeployment is in progress
DeployedDeployment completed successfully
FailedDeployment encountered an error
Not DeployedApp has not been deployed to this environment
View the Deployment History panel for the full deployment log, including outcome and any error details for failed deployments.

​
Post-deployment configuration

Apps whose Tables icon Tables or Elements icon Elements use Snowflake need extra steps in the target environment after deployment: pick database, schema, and table in that environment’s CloudLink, and map fields. Apps with no Snowflake dependencies are ready once deployment finishes.

​
Apps without external dependencies

For apps that don’t connect to Snowflake data:
  • Deployment completes immediately
  • Environment card shows green “Deployed” status
  • No additional configuration required
  • App is ready to use in the target environment

​
Apps with Snowflake dependencies

For apps with Tables icon Tables or Elements icon Elements linked to Snowflake, configure the data connections in the new environment.
1

Open configuration

After deployment completes, the Deploy button changes to Configure.The card shows:
  • Green “Deployed” status pill
  • “Complete” progress indicator
  • Configure button
Click Configure to open the target environment.
2

Review Items Needing Configuration

The Resolve Issues modal appears with the message: “Review and resolve configuration issues before proceeding with deployment.”The left panel lists all Datasets (Tables and Elements) that need configuration, each showing:
  • Dataset name
  • Configuration status (“Not configured”)
  • Error count indicating fields needing mapping
3

Select a Dataset

Click on a Dataset in the left panel to configure it.The right panel shows:
  • Dataset name and error count
  • “Configure data source connection and field mappings”
  • Valid fields count and errors count
4

Configure Data Connection

The CloudLink is pre-selected. Configure the data source:
  1. Database - Select the database from the dropdown
  2. Schema - Select the schema containing your data
  3. Table - Select the table that corresponds to this dataset
5

Map Fields

After selecting the table, map each field:
Target FieldAction
Field from the deployed appSelect the corresponding Source Field from the new environment’s table
For each Target Field listed:
  • Use the dropdown to select the matching Source Field
  • Ensure data types align (TEXT to TEXT, NUMBER to NUMBER, etc.)
  • Repeat for all fields in the dataset
6

Save Configuration

After mapping all fields for all datasets:
  1. Click Configure Dataset to save the configurations
  2. Configured items are removed from the list
  3. Continue until all items are configured
  4. When the list is empty, the modal closes
The app is now fully configured and ready to use in the target environment.

​
Deployment history

Each app keeps a log of deployments: who ran them, source and target environment, time, outcome (Success or Failure), and error details on failed runs. Error details stay on the record even after related background work is removed. Any user who can open the app can open Deployments and read this history. It is paginated and includes the full history, not only recent entries.
FieldDescription
Source environmentWhere the app was deployed from
Target environmentWhere it was deployed to
Initiated byUser who started the deployment
TimestampWhen the deployment started
OutcomeSuccess or Failure
Error detailsOn failures, shown on the same record

​
Example workflows

  1. Add a Development environment from Production.
  2. Deploy an app into Development and change it there.
  3. When satisfied, deploy from Development to Production.
  1. Add Staging (and optionally Development).
  2. Move apps Development → Staging for review, then Staging → Production when approved.
  1. Add a Training environment and deploy the apps users will see in Production so they can practice without touching live data.

​
Troubleshooting

Possible Causes:
  • CloudLink not configured in target environment
  • CloudLink credentials invalid or expired
  • Network connectivity issues
Solutions:
  1. Verify CloudLink is configured in the target environment
  2. Test CloudLink connection in Settings icon Organization Settings
  3. Check Snowflake service account permissions
Possible Causes:
  • Environment not yet created
  • Insufficient permissions to view environments
Solutions:
  1. Verify the environment exists in Settings icon Organization Settings > Environments
  2. Contact your administrator to check access permissions
Possible Causes:
  • Table structure differs between environments
  • Missing columns in target environment’s table
  • Data type mismatches
Solutions:
  1. Verify the target table exists and has the expected columns
  2. Check that column names match or can be mapped correctly
  3. Ensure data types are compatible between source and target
Possible Causes:
  • Deployment still in progress
  • App has no external dependencies (no configuration needed)
Solutions:
  1. Wait for deployment to complete (status shows “Deployed”)
  2. If no Configure button appears after deployment, the app has no Snowflake dependencies and is ready to use
Scenario: You need to use the same Snowflake user account with key-pair authentication for CloudLinks in environments that belong to different organizations.Solution: Snowflake supports key-pair rotation, which allows you to configure a second public key for the same user account. This enables environments in both organizations to authenticate simultaneously without disrupting existing connections.
Important: Key-pair rotation is only required when using the same Snowflake user across environments in different organizations. If you are using the same Snowflake user across multiple environments within the same organization, key-pair rotation is not necessary because they share the same public key.
Steps:
  1. Obtain the Public Key from the Organization You Are Adding the CloudLink To:
    • Navigate to Settings icon Organization Settings > CloudLinks in the organization where you want to add the CloudLink
    • Start creating a new Snowflake CloudLink
    • Select Key-pair authentication as the authentication method
    • Copy the public key displayed
  2. Configure Key-Pair Rotation in Snowflake:
    • Contact your Snowflake administrator to set the RSA_PUBLIC_KEY_2 property for the Snowflake user
    • Provide the public key copied from the organization where you’re adding the CloudLink
    • The Snowflake admin should run: 
      ALTER USER <username> SET RSA_PUBLIC_KEY_2='<public_key>';
  3. Complete CloudLink Setup:
    • After the second public key is configured in Snowflake, complete the CloudLink setup in the organization
    • Both organizations will now be able to authenticate with the same Snowflake user
    • The existing CloudLink in the other organization continues to work without interruption
For detailed information on configuring key-pair rotation in Snowflake, see Snowflake’s key-pair authentication documentation.

​
Deployment practices

  • Validate before Production — Deploy and test changes in non-production environments before deploying to Production.
  • Deploy one app at a time when practical so failures are easier to trace.
  • Use deployment history to confirm what ran, when, and by whom.
  • Restrict who can deploy to Production — Grant DEPLOY_APPS in Production only to release-managers; review that role membership periodically. Because role membership is environment-specific, removing DEPLOY_APPS in Production does not affect a user’s ability to deploy in Development or Staging.

​
Next steps

Understand and Configure Environments

Environment concepts, categories, CloudLink requirements, and setup steps

CloudLink Overview

Detailed CloudLink configuration options

Snowflake Connection

Complete Snowflake setup guide with scripts

Apps Overview

Understanding apps and their components