Workflow activities

Get Environment Variable

Properties​

Common​

• DisplayName - The display name of the activity. This field supports only Strings or String variables.

Input​

• Variable - The name of the environment variable whose value is to be retrieved. This field supports only Strings or String variables.

Output​

• VariableValue - The value of the selected environment variable.

Misc​

• Private - If selected, the values of variables and arguments are no longer logged at Verbose level.

Platform-specific behavior​

Windows environment​

• The activity first attempts to retrieve the variable from the User level (EnvironmentVariableTarget.User).
• If not found at the User level, it falls back to the Process level environment variables.
• This fallback mechanism ensures that both user-specific and process-specific variables are accessible.
• System properties exposed through System.Environment (e.g., MachineName, OSVersion, UserName) are always checked first regardless of scope.

Cross-platform environment​

• The activity retrieves variables only from the Process level (EnvironmentVariableTarget.Process).
• This includes variables inherited from the parent process and any set during the current process execution.
• No fallback mechanism is used since User-level variables are Windows-specific.
• System properties exposed through System.Environment are still prioritized and accessible.

Retrieval priority​

1. System.Environment Properties (all platforms)​

• First checks if the requested variable name matches a built-in .NET property (e.g., CurrentDirectory, MachineName, ProcessorCount).
• If matched, returns the property value directly.

2. Environment Variables​

• Windows: Checks User level first, then falls back to Process level.
• Cross-Platform: Checks Process level only.

Technical details​

• "windows" - Uses EnvironmentVariableTarget.User with Process-level fallback.
• "portable" - Uses EnvironmentVariableTarget.Process only.

Behavioral differences​

Variable persistence​

• Windows: Can retrieve persistent user-level variables set through Windows system settings or by the Set Environment Variable activity.
• Cross-Platform: Only retrieves variables available in the current process scope (inherited from shell or set during execution).

Variable scope​

• Windows: Has access to a wider scope of variables (User + Process).
• Cross-Platform: Has access to a narrower scope (Process only).

Best practices​

• For Windows workflows, you can rely on user-level environment variables for configuration. The automatic fallback ensures process-level variables are still accessible.
• For cross-platform workflows, only rely on environment variables passed to the process or set during execution. Do not depend on user-level variables as they won't be available. Consider passing required configuration through process arguments or configuration files.
• For portable workflows, design workflows assuming Process-level scope only to ensure consistent behavior across platforms. Test that all required variables are available at process startup and document any environment prerequisites clearly.
• System properties: Prefer using .NET's built-in System.Environment properties (like MachineName, UserName) when available, as they work consistently across platforms.

Return value​

• Returns the environment variable value as a string.
• Returns empty string or null if the variable is not found (behavior may vary by platform and .NET version).
• System property values are returned as strings using .ToString().

Example scenarios​

Scenario 1: Reading PATH variable​

• Windows: Successfully retrieves from User or Process scope.
• Linux/macOS: Successfully retrieves from Process scope.

Scenario 2: Reading a user-specific custom variable set via Windows System Properties​

• Windows: Successfully retrieves the value.
• Linux/macOS: Returns empty/null (user-level variables don't exist).

Scenario 3: Reading MachineName​

• All Platforms: Successfully retrieves from System.Environment.MachineName property.