Skip to main content
Labs feature. Environments are 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.
An organization environment is a separate Elementum workspace tied to your production organization. You can build and test changes without affecting live workflows, then copy app configurations to another environment when you are ready.

​
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
Your organization begins with Production—the default, live environment. You can add environments for purposes such as Development, Testing, Staging, and Training. Environments do not share app configuration by default; you move configuration between them using deployment. See Deploy Apps between Environments for how that works. Why teams use multiple 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

​
Environment categories

Every environment belongs to one of four categories. The category determines the color and icon shown on the persistent indicator visible throughout the platform.
CategoryColorIconDescription
DevelopmentOrangeTriangleAn environment to build and experiment with new ideas without affecting anyone else.
TestYellowSquareAn environment to review your work and make sure everything clicks before moving forward.
StageGreenPentagonAn environment to host demos or beta users and verify everything is perfect before the final release.
ProductionBlueCircleAn environment to host the finished, live version of your app where your actual users interact with your work.
Every authenticated user sees the same indicator regardless of role — there is no permission gate on viewing it. Production is locked. The Production category is reserved for the default Production environment. It cannot be selected when creating a new environment, and the Production environment’s category cannot be changed after creation. Pre-existing environments. When this feature is enabled, the Production environment is automatically assigned the Production category. All other existing environments are assigned Development by default. Org Admins can update those assignments afterward.
Each environment needs its own CloudLink configuration. Set up credentials in the environment before deployed apps can use Snowflake-backed data there.
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

ComponentRequirement
UserOne Snowflake user per environment (for example ELEMENTUM_DEV, ELEMENTUM_PROD)
RoleOne role per environment
DatabaseOne database per environment for platform data
SchemaA dedicated platform schema in that database
This separation limits cross-environment access to platform data and supports auditing. External (non-platform) tables can be shared across environment users if your governance allows it; changes to those shared tables are visible in every environment that uses them. Example
EnvironmentUserRolePlatform databasePlatform schema
ProductionELEMENTUM_PRODELEMENTUM_PRODELEMENTUM_PRODELEMENTUM_PLATFORM
DevelopmentELEMENTUM_DEVELEMENTUM_DEVELEMENTUM_DEVELEMENTUM_PLATFORM
StagingELEMENTUM_STAGINGELEMENTUM_STAGINGELEMENTUM_STAGINGELEMENTUM_PLATFORM

​
Create an Environment

Create a new environment from your production organization to start developing and testing in isolation.
  1. Go to Settings icon Organization Settings > Platform > Environments. You will see a list of all environments in your organization, with Production marked as the default.
  2. Click + Create Environment in the upper right. A modal appears with the message: “Create an environment that allows you to safely build, test, and release changes without affecting your live app.”
  3. Fill in the required fields:
    FieldDescriptionExample
    Environment nameA descriptive name for the environmentDevelopment, Testing, Staging
    SubdomainThe URL prefix for this environmentdev, test, staging
    DescriptionOptional description of the environment’s purposeFor testing new features before production
    CategoryThe environment type that controls its color and icon throughout the platformDevelopment, Test, Stage
    The subdomain creates the environment’s URL: [subdomain]-[yourorg].elementum.io
  4. Click Create Environment. The new environment appears in the list with its own card showing the name, description, and domain.
When a new environment is created, Elementum clones the roles and role membership from Production into that environment as its starting state. The user who creates the environment is also added to the Admin role so they can configure CloudLink and adjust membership without an additional access request. Admin is one of the managed roles in Roles & Permissions — every organization has it by default, and it cannot be deleted or have its permissions modified. After environment creation, role membership becomes environment-specific — see Environment-specific role membership for details.

​
Change an Environment’s Category

You can update an environment’s category at any time after creation. The Production environment’s category is locked and cannot be changed.
  1. Go to Settings icon Organization Settings > Platform > Environments.
  2. Find the environment and click Edit on its card.
  3. In the edit environment panel, select a new value for the Category field.
  4. Click Save.
The Production category cannot be assigned to any environment other than the default Production environment, and the Production environment’s category cannot be changed.
After creating an environment, configure CloudLink to connect the environment to your data warehouse.
CloudLink must be configured before you can deploy apps that use Snowflake-connected Tables icon Tables or Elements icon Elements. Apps deployed without a valid CloudLink connection cannot access data.
Create dedicated Snowflake users, roles, databases, and schemas per environment before you connect CloudLink. Full isolation rules and examples are in Isolating platform data above.
1

Open Environment Configuration

From the Environments list, find your new environment and click the Configure button on its card.This opens the environment configuration page showing the environment name, status, and domain configuration.
2

Access CloudLink Settings

Click the Manage CloudLink Credentials button.This opens the new environment in a new tab/window, navigating directly to the CloudLinks settings page.
3

Edit CloudLink Connection

On the CloudLinks page, click the Edit button on the CloudLink entry.The Edit CloudLink modal appears with the following fields:Connection Settings:
  • Name - Identifier for this CloudLink connection
  • Username - Snowflake service account username
  • URL - Your Snowflake account URL (for example, your-account.snowflakecomputing.com)
  • Authentication Method - Select Password or Key-pair authentication
  • Password - Service account password (if using password authentication)
Resource Scheduler:
  • Interval - Sync frequency (default: 20 minutes)
  • Time unit - Minutes, Hours, or Days
The default sync interval is 20 minutes. Shorter intervals provide faster data updates but increase Snowflake credit consumption.
4

Configure Data Connection

After entering valid credentials, additional fields become available:
  • Role - Select the Snowflake role for this connection
  • Warehouse - Select the Snowflake warehouse to use
  • Database - Select the database where Elementum stores platform data
The Database field is where Elementum creates its platform tables. Select or create a dedicated schema for Elementum. Do not use your business data schema here.
5

Save Configuration

Click Save to apply the CloudLink configuration.The connection is tested automatically. Once successful, the environment is ready for app deployments.
For detailed Snowflake configuration including IP whitelisting and permissions, see the Connecting Snowflake to Elementum guide.

​
Environment-specific role membership

There are two distinct concepts when it comes to roles and environments:
  • Role definitions (what permissions a role grants, creating or deleting roles) — these changes are mirrored across all environments. When you modify a role’s permissions, create a new role, or delete a role in any environment, that change applies everywhere.
  • Role membership (who belongs to a role) — at environment creation, roles and role membership are cloned from Production into the new environment as its starting state. After that, membership is tracked per environment: changes you make in one environment do not propagate to others, so granting a user a role in Development does not also grant the same role in Staging or Production.
“Role changes” in the context of environments refers to the role itself — its permissions, creation, or deletion — not who belongs to it. Membership is mirrored once at environment creation, then managed separately in each environment afterward.
BehaviorWhat it means
Cloned at environment creationWhen you create a new environment, the roles and role membership from Production are cloned into it as the starting state. After creation, membership changes are environment-specific.
Per-environment assignmentsA user or group must be added to a role in each environment where the access is needed. The same role exists in every environment, but its members are stored independently.
Creator gets the Admin roleThe user who creates a new environment is also added to the Admin role for that environment so they can configure CloudLink and grant access to others. Admin is one of the managed roles in Roles & Permissions — every organization has it by default, and its permissions cannot be modified or deleted.
Same role management UIAdmins manage membership through the existing Roles & Permissions screens. The screen always edits the role in the environment you are currently signed in to.
Groups governed in ProductionGroups and group membership are managed in the Production environment and remain consistent across all environments. You will not see Group Admin options in non-production environments.
Membership is independent of deploymentDeploying an app, element, or task into an environment does not carry over role membership from the source environment. After the first deployment, configure role membership for those objects on the object’s Roles & Permissions page in the target environment. No future redeployment will overwrite membership settings you have configured.
Data Access policies are environment-specificAccess policy changes you make outside of a deployment apply only to the environment you are signed in to. Removing a group’s access to an app in one environment does not remove it elsewhere — to change access across all environments, repeat the change in each one. See Initial vs. subsequent deployments for how access policies behave during a deployment.

​
Add or remove users and groups in a specific environment

  1. Sign in to the environment whose membership you want to change. The persistent environment indicator confirms which environment you are working in.
  2. Open Settings icon Org Settings > Roles & Permissions for organization roles, or open Roles & Permissions under Security in an app menu for that app’s roles.
  3. Click Manage Membership on the role you want to change.
  4. Add or remove the relevant users and groups, then save. The change applies only to the current environment. To grant the same access in another environment, repeat the steps after switching to that environment.
For role definitions, the difference between managed and custom roles, and the full permission list, see Roles & Permissions.

​
Practices to follow

  • Naming and category — Use clear names (Development, QA, Staging, Training) and assign the matching category so the purpose of each environment is obvious to every user at a glance; keep both consistent across your organization.
  • CloudLink — Prefer separate Snowflake service accounts per environment; document which databases and schemas each environment uses; confirm connections stay healthy.
  • Access — Restrict who can create environments and deploy apps; review role membership in each environment separately, since assignments are not shared across environments; use non-production accounts for testing where appropriate.

​
Next steps

Deploy Apps between Environments

Move app configuration from one environment to another and complete post-deployment setup

CloudLink Overview

Configure CloudLink connections for your environments

Snowflake Connection

Detailed guide for connecting Snowflake to Elementum

Apps Overview

Learn about apps and how they organize your business processes