• Startup
• Business
• Enterprise
• On-Premise
• Add-on

Overview

Environment variables provide a simple, secure, and reusable way to manage configuration values across your Etlworks instance. They are especially useful for credentials, connection strings, or values that change depending on the environment (for example, dev, staging, or production).

Setting Environment Variables

You can define environment variables in Settings → Customization under two separate sections:

• Environment Variables

• Secure Environment Variables

Only super admin users can define or modify environment variables. Once set, they are available globally and work for all tenants within the instance.

• Environment Variables store plain-text values such as region names, email addresses, or file paths.

• Secure Environment Variables store encrypted values such as passwords, tokens, or API keys. Their values are masked in the UI and decrypted only at runtime.

Example:

Type	Key	Value
Environment Variable	EMAILS	alerts@company.com
Environment Variable	ENV_NAME	DEV
Secure Environment Variable	OPENAI_API_KEY	********

Referencing Environment Variables

To use an environment variable, reference it anywhere in Etlworks using the syntax:

${VARIABLE_NAME}

For example, ${EMAILS} will be replaced at runtime with the value of the EMAILS variable.

Note: Names of the environment variables are case sensitive. 

Where Environment Variables Can Be Used

Environment variables can be referenced in nearly all areas of Etlworks where string parameters are accepted.

Schedule

Flow Parameters

You can reference them in both Flow parameters and Secure parameters.

Example:

Key	Value
EMAILS	${EMAILS}
ENV_NAME	${ENV_NAME}

Emails

In schedules or flows that send notifications, you can use environment variables in the Emails field:

Example:

${EMAILS}

At runtime, Etlworks will send emails to the address or list of addresses defined in the variable.

Retry Exception Masks

You can use environment variables in Retry Exception Mask and Retry Exception Mask (exclude) fields.

This is helpful when you need environment-specific retry logic or exception handling rules that vary across environments.

Agents and Manual Flow Execution

When running a flow manually or configuring an Agent, environment variables can be used in all Flow parameters and Secure parameters fields.

This lets you execute the same flow across multiple environments without changing configuration values each time.

Connections

Environment variables can be used in any string field of a connection configuration, including credentials.

Example:

Field	Value
Host	db.${ENV_NAME}.company.local
User	etl_user
Password	${DB_PASSWORD}

Flows

Transformations

Environment variables can be referenced in:

• From and To
• Inside SQL queries
• In the Code transformations
• In transformation parameters

Mapping

Environment variables can be referenced in mapping in From and To:

And in Field Function:

Real-Life Use Cases

Use Case 1: Multi-environment Deployment

You can define ENV_NAME as dev, staging, or prod and reuse it in flow names, connection strings, and queries.

Example:

Source in transformation: ${ENV_NAME}.customers

The flow will automatically adjust to each environment without manual edits.

Use Case 2: Centralized Email Notifications

Define one variable EMAILS containing a list of alert recipients.

Use ${EMAILS} in the schedule’s notification settings, so when recipients change, you update only one variable.

Use Case 3: Secure Credentials

Store passwords in secure environment variables like ${OPENAI_API_KLEY} and use them in multiple connections.

This keeps sensitive data encrypted and consistent across all flows.

Best Practices

• Use Environment Variables for non-sensitive values and Secure Environment Variables for credentials.

• Use consistent naming, such as ENV_, DB_, or API_ prefixes.

• Avoid hardcoding environment-specific values in flows or connections.

• Update environment variables to propagate changes automatically to all dependent flows and connections.