Organization environments
Each environment:- Uses its own subdomain (for example
dev-yourorg.elementum.io) - Needs its own CloudLink configuration to reach your data warehouse
- Holds its own copies of apps you deploy into it
- Runs independently of other environments
- Develop and change apps without risking production data or workflows
- Validate behavior with realistic configuration before go-live
- Let several people work in parallel in separate workspaces
- Release changes in a controlled way after review
Deploying apps between environments
Deployment copies an app and its configuration from a source environment to a target environment. The deployment is tracked with status and history on the app’s Deployments page. 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.Subsequent deployment behavior
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:| Configuration | Initial deployment | Later deployments |
|---|---|---|
| AI Search target lag | Copied from source | Target environment’s value is kept |
| Access policies | Copied from source | Target 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.
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.| Field | Description |
|---|---|
| Source environment | Where the app was deployed from |
| Target environment | Where it was deployed to |
| Initiated by | User who started the deployment |
| Timestamp | When the deployment started |
| Outcome | Success or Failure |
| Error details | On failures, shown on the same record |
CloudLink and platform data
Isolated environments need separate warehouse connections. Plan Snowflake users, roles, databases, and schemas before you connect CloudLink; then verify the connection works before relying on deployments.Isolating platform data
| Component | Requirement |
|---|---|
| User | One Snowflake user per environment (for example ELEMENTUM_DEV, ELEMENTUM_PROD) |
| Role | One role per environment |
| Database | One database per environment for platform data |
| Schema | A dedicated platform schema in that database |
| Environment | User | Role | Platform database | Platform schema |
|---|---|---|---|---|
| Production | ELEMENTUM_PROD | ELEMENTUM_PROD | ELEMENTUM_PROD | ELEMENTUM_PLATFORM |
| Development | ELEMENTUM_DEV | ELEMENTUM_DEV | ELEMENTUM_DEV | ELEMENTUM_PLATFORM |
| Staging | ELEMENTUM_STAGING | ELEMENTUM_STAGING | ELEMENTUM_STAGING | ELEMENTUM_PLATFORM |
Data connections after deployment
Apps whose Tables or 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. To get started, see Set up Environments and Deploy Apps.Example workflows
Develop, then release
Develop, then release
- Add a Development environment from Production.
- Deploy an app into Development and change it there.
- When satisfied, deploy from Development to Production.
Staging before production
Staging before production
- Add Staging (and optionally Development).
- Move apps Development → Staging for review, then Staging → Production when approved.
Training
Training
- Add a Training environment and deploy the apps users will see in Production so they can practice without touching live data.
Practices to follow
- Naming — Use clear names (
Development,QA,Staging,Training) so the purpose of each environment is obvious; keep naming consistent across your organization. - CloudLink — Prefer separate Snowflake service accounts per environment; document which databases and schemas each environment uses; confirm connections stay healthy.
- Deployments — Validate in non-production environments before Production; deploy one app at a time when practical so failures are easier to trace; use deployment history to see what ran.
- Access — Restrict who can create environments and deploy apps; use non-production accounts for testing where appropriate; review access periodically.
Next steps
Set up Environments and Deploy Apps
Create environments, configure CloudLink, and deploy apps step by step
CloudLink Setup
Configure CloudLink connections for your environments
Apps Overview
Learn about apps and how they organize your business processes
Snowflake Connection
Detailed guide for connecting Snowflake to Elementum