Environments and Promotion

Environments allow you to create isolated workspaces based on your production organization. You can safely build, test, and refine apps without affecting your live environment, then promote changes when ready.

​

What Are Environments?

An environment is a separate instance of your Elementum organization where you can develop and test changes in isolation. Each environment:

• Has its own subdomain (e.g., dev-yourorg.elementum.io)
• Requires its own CloudLink configuration to connect to data
• Contains independent copies of deployed apps
• Operates completely separate from production

​

How Environments Work

Your organization starts with a Production environment - the default, live environment where your business processes run. From Production, you can create additional environments for different purposes:

• Development - For building new features and experimenting
• Testing - For QA validation before production release
• Staging - For final verification with production-like data
• Training - For onboarding users without affecting live data

Each environment operates independently but can exchange app configurations through the deployment process.

​

What Is Promotion (Deployment)?

Promotion is the process of copying an app and all its configurations from one environment to another. When you deploy an app:

• All app configurations are copied to the target environment
• Associated objects (automations, layouts, flows, approval processes, etc.) are included
• The deployment is tracked with status and history

​

Deployment Direction

You can deploy apps in any direction:

• Environment to Production - Push tested changes to your live environment
• Production to Environment - Copy a production app to test modifications
• Environment to Environment - Move apps between development, testing, or staging

​

What Gets Deployed

When you deploy an app, the following configurations are included:

​

Environment Requirements

​

CloudLink Configuration

Since environments are isolated, they need independent connections to your data warehouse. After creating an environment:

1. Configure CloudLink with appropriate Snowflake credentials
2. Ensure the service account has access to required databases and tables
3. Verify the connection before deploying apps

​

Post-Deployment Configuration

Apps with Tables or Elements linked to Snowflake require additional configuration after deployment:

• Database Selection - Choose the database in the new environment’s CloudLink
• Schema Selection - Select the appropriate schema containing your data
• Table Selection - Map to the corresponding table in the new environment
• Field Mapping - Match source fields to target fields for each dataset

Simple apps without external data dependencies deploy immediately without additional configuration.

​

Use Cases

​

Development and Testing Workflow

1. Create a “Development” environment from Production
2. Deploy an existing app to Development for modifications
3. Make and test changes in the Development environment
4. When ready, deploy the updated app back to Production

​

Staging for Quality Assurance

1. Create a “Staging” environment that mirrors Production
2. Deploy apps from Development to Staging for QA review
3. Validate functionality with production-like data
4. After approval, deploy from Staging to Production

​

Training and Sandbox

1. Create a “Training” environment for user onboarding
2. Deploy apps that users will work with in production
3. Allow users to practice without affecting live data
4. Update Training environment as Production apps evolve

​

Best Practices

​

Environment Naming

Use clear, descriptive names that indicate the environment’s purpose:

• Development or Dev - For active development work
• Testing or QA - For quality assurance validation
• Staging - For pre-production verification
• Training - For user onboarding and practice

​

CloudLink Management

• Use separate Snowflake service accounts for each environment when possible
• Document which databases and schemas each environment accesses
• Regularly verify CloudLink connections are active and healthy

​

Deployment Strategy

• Test thoroughly in non-production environments before deploying to Production
• Use consistent naming conventions across environments
• Document deployments and track changes in deployment history
• Deploy one app at a time to isolate issues

​

Access Control

• Limit who can create environments and deploy apps
• Use separate user accounts for testing in non-production environments
• Review environment access periodically

​

Next Steps