Understand and Configure Environments

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. 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.

​

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

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

​

Create an Environment

Create a new environment from your production organization to start developing and testing in isolation.

1. Go to 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:

   Field	Description	Example
   Environment name	A descriptive name for the environment	Development, Testing, Staging
   Subdomain	The URL prefix for this environment	dev, test, staging
   Description	Optional description of the environment’s purpose	For testing new features before production
   Category	The environment type that controls its color and icon throughout the platform	Development, 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.

​

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 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.

​

Configure CloudLink

After creating an environment, configure CloudLink to connect the environment to your data warehouse. 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. 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.

​

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 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