Global Variables

Global Variables let one automation step pass values to later steps during the same task run. They are useful for chaining outputs (for example script output, generated IDs, or runtime secrets) without hard-coding values.

Variable Sources

A task run can receive variables from several sources:

• Linked custom parameter values entered at execution time are added when the run starts.

• Certificate system variables are pre-populated for certificate task runs.

• Script output variables can be appended by script steps while the run is executing.

• Integration output variables can be created by supported steps such as TOPdesk incident creation and Active Directory actions.

Variables are scoped to one task run. They are available to later steps in that run and stored with run history.

Using Variable References

In supported parameter fields, choose Variable as the value source and select from the available variables dropdown. Use custom variable name only when you need to reference a variable that is produced at runtime and is not yet in the dropdown.

The stored value uses double-brace placeholder syntax:

Runtime replacement is applied to supported string fields, including:

• Script step parameter values.

• Runbook and Run Command parameter values.

• Service action fields (name, display name, description, startup parameters).

• Certificate install fields (store path, PFX path/password, post-script content).

• Key Vault certificate fields (vault URI and certificate name).

• DevOps pipeline parameter values and branch field.

• TOPdesk incident fields such as brief description, request text, action text, caller, category, and target incident number/id.

• Active Directory fields such as sAMAccountName, distinguished name, display name, mail, password, OU, group, and attribute JSON.

• Azure resource action, Azure certificate deployment, SCOM, Citrix ADC, Application Proxy, and Application Gateway fields where variable-enabled inputs are shown.

Variable Picker and Expected Output

When you choose Variable in a supported step field, the dropdown shows the variables AZExecute already knows about. This includes linked custom parameters, system variables, and expected output from earlier steps in the task.

• Custom variables come from linked custom parameters and are supplied when the run starts.

• System variables come from the task context, such as certificate renewal information.

• Step output variables are expected values from earlier steps, such as TOPdesk incident numbers or Active Directory object identities.

Scripts can create any variable name, so AZExecute cannot always predict script output before the script runs. For those cases, use a custom variable name and make sure the script writes the matching output marker.

Creating Variables from Script Output

Script steps can create variables by writing lines in this format:

::azx-set-var:VariableName=VariableValue

Example:

$serverName = $env:COMPUTERNAME Write-Host "::azx-set-var:ServerName=$serverName" $deploymentId = "deploy-$(Get-Date -Format 'yyyyMMdd-HHmmss')" Write-Host "::azx-set-var:DeploymentId=$deploymentId"

Output variable marker lines are captured as variables and removed from the visible step output stored in history. Keep normal logging separate from variable marker lines.

The legacy ##vso[task.setvariable...] syntax is not the runtime parser format used by current agent step execution.

Integration Output Variables

Some integration steps create known variables automatically. These variables are visible in history and can be selected in later step fields when AZExecute can predict the output name.

TOPdesk Create Incident

• {{ topdesk_incident_number }}

• {{ topdesk_incident_id }}

• Step-scoped and reference-scoped versions when a step id or saved reference name is available.

Active Directory Actions

• {{ samAccountName }}

• {{ distinguishedName }}

• {{ objectGuid }}

• Namespaced values such as {{ active_directory_user_sam_account_name }} or {{ active_directory_group_distinguished_name }}.

• Step-scoped versions for tasks that create or update multiple AD objects in one run.

When a later step needs a specific result, prefer the more specific variable name. For example, use a step-scoped or namespaced Active Directory variable instead of the generic {{ samAccountName }} when the task has several AD steps.

Certificate Task System Variables

Certificate task runs include built-in certificate variables when data is available:

• CertificateThumbprint

• CertificateSubject

• CertificateExpiration

• CertificateCommonName

• CertificatePrimaryDomain

• CertificateFriendlyName

• CertificatePassword

Variable Lifecycle and History

1. A run starts and initial variables are created (custom input values + system values where applicable).

2. Steps execute and supported step output can append additional variables.

3. Variables are stored encrypted and shown in run details to authorized users.

4. History views can reveal/copy variable values for troubleshooting.

Variable values are encrypted at rest and decrypted only for allowed views or step execution flows that require plaintext.

Parallel Execution Considerations

Steps or groups running in parallel should not assume variables from sibling parallel work are already available.

• Create shared variables in an earlier group that completes before consuming groups start.

• Keep parallel branches independent when possible.

• If branches must share data, merge results in a later sequential group.

Troubleshooting

Variable not replaced

• Check spelling in both declaration and placeholder. Variable lookup is case-insensitive, but clear naming still avoids confusion.

• Confirm the producing step completed before the consuming step runs.

• Verify the field supports runtime replacement (not every field type is replaced).

• Check whether the producing and consuming steps were placed in parallel groups. Parallel work should not depend on sibling output.

Script variable did not appear

• Ensure the script writes exactly: ::azx-set-var:Name=Value.

• Check script output in step run logs to confirm the line was emitted.

• Avoid spaces or special characters in variable names. Use letters, numbers, underscore, hyphen, or dot.