Task Steps

Task steps are the executable units inside an automation task. This page explains the currently available step types, what each step requires, and how to configure steps so executions are predictable in production.

Step availability depends on task type. General and Certificate tasks do not expose the exact same step set.

Step Availability by Task Type

Available for General and Certificate Tasks

• PowerShell Script

• Bash Script

• Runbook

• Run Command

• Manage Windows Service

• Execute DevOps Pipeline

• Azure Resource Action

• TOPdesk Incident

• TOPdesk Change

• Active Directory Action

• SCOM Maintenance Mode

• Windows DNS

• Simply.com DNS

• Azure DNS

• Amazon Route 53 DNS

• Cisco Umbrella

• Copy Files

• Zip / Unzip

Certificate-Only Step Types

• Azure Application Gateway

• Azure Key Vault (certificate target)

• Certificate Install

• Citrix ADC / NetScaler Certificate

• Application Proxy Certificate

• Application Certificate

• Azure Certificate Deployment

PowerShell Script Step

Executes a stored script on a selected AZExecute client machine.

Required: Client Machine + Script

Optional: PowerShell version and script parameter values

• PowerShell version selector is shown when the selected machine reports PowerShell Core support.

• Parameters support static values, linked task parameters, and variables created by earlier steps.

• Scripts can create output variables for later steps by writing ::azx-set-var:Name=Value to output.

• Output variable names can contain spaces and punctuation, but not = or line breaks. Later steps reference them with {{ Name }}.

• If the script imports PowerShell modules, assign those modules to the selected agent or its agent group before running the task.

• Good fit for custom logic and legacy integration on managed machines.

For reusable dependencies, manage Gallery and custom modules in PowerShell Modules instead of adding installation logic to every script.

Bash Script Step

Executes a stored Bash script on a selected Linux-capable AZExecute client machine.

Required: Client Machine + Script

Optional: Script parameter values

• Use for Linux-based automation and shell workflows managed by AZExecute agents.

• Parameters support the same variable reference pattern as other task steps.

• Keep script output readable; only write output variable markers for values that later steps need.

Runbook Step

Executes a runbook from an Azure Automation Account.

Required: Automation Account + Runbook + Run On target

Optional: Runbook parameters

• Run On can be Azure (cloud) or a Hybrid Worker Group.

• Parameter inputs are generated from the selected runbook parameter definitions.

• Use for Azure-native operations or workflows already standardized in runbooks.

Run Command Step

Runs a stored script on an Azure VM through Azure Run Command.

Required: Subscription + Virtual Machine + Script

Optional: Script parameters

• VM list is loaded from the selected subscription.

• Includes script preview and parameter input when script parameters exist.

• Best for short/medium remote actions on Azure VMs without deploying AZExecute client agent there.

For complex long-running orchestration, prefer a Runbook or agent-based PowerShell step.

Azure Key Vault Step (Certificate Tasks)

Targets a Key Vault certificate entry for certificate deployment/update.

Required: Key Vault + Certificate Name

• Key Vault picker is grouped by tenant and supports cross-tenant visibility based on settings/access.

• You can select an existing certificate name or type a new one.

• Use this to keep certificate targets centralized for Azure workloads.

Certificate Install Step (Certificate Tasks)

Installs certificates on a selected AZExecute client machine.

Required: Client Machine

Optional: PFX export, cleanup, IIS binding update, binding entries

• Supports private key exportability and optional PFX export path/password.

• Supports cleanup of older certificates generated by AZExecute naming pattern.

• IIS binding updates can be configured with one or many binding entries.

Windows Service Action Step

Performs service operations on a selected AZExecute client machine.

Required: Target Machine + Service Name + Action

Optional: Startup Type + Startup Parameters (for Configure action)

• Service Name expects the internal service name, not display text.

• Actions include Start, Stop, Restart, and Configure.

• Common in post-deployment sequences (for example after cert or config updates).

Azure Application Gateway Step (Certificate Tasks)

Targets Azure Application Gateway certificate integration in certificate workflows.

Required: Application Gateway target details based on your environment configuration

This step type is available for Certificate tasks only and is intended for certificate-centric automation paths.

Execute DevOps Pipeline Step

Triggers Azure DevOps pipelines from within your task workflow.

Required: Organization + Project + Pipeline

Optional: Branch + pipeline parameters

• Organizations are listed by tenant and then projects/pipelines are loaded progressively.

• Branch suggestions are loaded from pipeline details.

• Pipeline parameters support task-level variable usage through linked custom parameters.

Azure Resource Action Step

Runs a targeted action against an Azure resource, such as operational actions for App Service, virtual machines, or other supported Azure resources.

Required: Azure resource selection + supported action

• Use this when the workflow needs to start, stop, restart, or otherwise operate on an Azure resource.

• Resource and action availability depends on your tenant access and the selected resource type.

• Resource fields can use variables from earlier steps, which is useful in reusable deployment workflows.

TOPdesk Incident and Change Steps

Creates, updates, assigns, closes, cancels, archives, or unarchives TOPdesk records using a configured TOPdesk integration. Use the Incident step for operational incidents and the Change step when the workflow needs to open or update formal change records.

Required: TOPdesk integration + operation-specific incident or change fields

Optional: Saved incident reference name, caller lookup, category, operator group, processing status, and action text

• Create operations can publish output variables such as {{ topdesk_incident_number }} and {{ topdesk_incident_id }}.

• If you set a saved reference name, later TOPdesk update, close, cancel, archive, or unarchive steps can target the same record without manually entering the number.

• Step-scoped variables are also available for tasks that create more than one TOPdesk record in the same run.

Use a clear reference name such as employee_onboarding_ticket when a later step should update or close the incident created earlier.

Active Directory Action Step

Performs Active Directory actions through an AZExecute agent with access to the target domain.

Required: Active Directory integration + operation-specific identity fields

Operations: Create User, Create Group, Add Group Member, Update User Attributes

• Create User and Create Group can publish values such as {{ samAccountName }}, {{ distinguishedName }}, and {{ objectGuid }}.

• Namespaced variables such as {{ active_directory_user_sam_account_name }} or {{ active_directory_group_distinguished_name }} help keep multi-step tasks readable.

• Use step-scoped variables when one task creates multiple users or groups and later steps must reference a specific step's result.

Active Directory actions require a Windows AZExecute agent that can reach the domain and load the Active Directory PowerShell module. If the module is not already available on the target, assign it through PowerShell Modules.

SCOM Maintenance Mode Step

Starts or stops SCOM maintenance mode through an enabled SCOM integration. The integration targets a connected Windows AZExecute agent; AZExecute does not store separate SCOM credentials for this step.

Required: SCOM integration + target managed computer + operation

Optional: duration, comment, reason, and management server override

• Configure SCOM integrations from Tenant Admin > Integrations > SCOM.

• The selected integration must point to a currently connected Windows agent with the OperationsManager PowerShell module available.

• The integration can specify a SCOM management server, or leave it blank to use the agent machine's existing SCOM connection context.

• Managed computer lookup and maintenance-mode actions are sent to the connected agent through the AZExecute agent console channel.

• Use before planned changes to suppress avoidable monitoring alerts.

• Place the start step before deployment work and the stop step in a later cleanup or verification stage.

• Keep SCOM steps sequential when deployment steps depend on maintenance mode being active first.

SCOM steps fail if the selected agent is offline, not Windows-based, cannot load the OperationsManager module, or cannot reach the configured SCOM management server.

DNS and Network Security Steps

DNS and network-security steps let a task create, update, or remove name-resolution records without asking operators to leave the workflow. They are useful for certificate validation, onboarding, decommissioning, and environment provisioning.

• Windows DNS: manages Windows-hosted or AD-integrated DNS zones and records through a connected Windows agent.

• Simply.com DNS: manages records through a configured Simply.com integration.

• Azure DNS: manages Azure DNS records through configured Azure DNS credentials.

• Amazon Route 53 DNS: manages Route 53 records through a configured AWS account integration.

• Cisco Umbrella: manages internal domains and destination-list entries through an AZExecute agent.

DNS steps are strongest when paired with variables. For example, a task can build a record name from a requested application name, create the DNS entry, then pass the resulting record details to a verification or ticketing step.

Copy Files Step

Copies files or folders between AZExecute agents and Azure Blob Storage. Use it when a workflow needs to stage installers, collect logs, move generated output, or hand files from one environment boundary to another.

Required: transfer type + agent/storage selections + source and destination paths

Transfer types: Agent to Agent, Agent to Azure Blob, Azure Blob to Agent

• Agent-to-agent copies use paths reachable by the selected agents.

• Blob transfers use a selected storage account, container, and blob name or prefix.

• Output includes transfer type, source, destination, storage metadata, file count, and a structured copy_file_details JSON variable for later steps.

Place file-producing steps before copy steps, and avoid parallel execution when the copy depends on files created earlier in the same run.

Zip / Unzip Step

Creates or extracts zip archives on a selected AZExecute agent. The step uses built-in .NET archive handling, so the same task design can work across Windows and Linux agents without relying on external zip tools.

Required: operation type + agent + source path + destination path

Operations: Zip or Unzip

• Zip creates an archive from a file or folder on the selected agent.

• Unzip extracts a zip archive to a folder on the selected agent.

• Optional overwrite behavior controls whether existing destination files can be replaced.

• Output includes operation type, source, destination, archive path or extraction folder, entry count, and a structured archive_details JSON variable.

A common pattern is to generate files with a script, zip the output folder, upload the archive to Azure Blob Storage with Copy Files, and then write the archive path into a TOPdesk incident or completion notification.

Certificate Integration Steps

Certificate tasks can deploy renewed certificates to several target systems. These steps usually consume certificate system variables and should run after the certificate has been issued.

• Citrix ADC / NetScaler Certificate: uploads and binds a certificate on Citrix ADC / NetScaler.

• Application Proxy Certificate: updates the SSL certificate for a Microsoft Entra Application Proxy enterprise application.

• Application Certificate: uploads a renewed certificate to an AZExecute-managed Microsoft Entra application registration.

• Azure Certificate Deployment: deploys a certificate to Azure-native services such as App Service, API Management, Container Apps, Front Door, CDN, or Kubernetes.

For certificate tasks, prefer variables such as certificate thumbprint, subject, common name, friendly name, password, and target-specific names instead of hard-coded certificate values.

Common Step Behavior

• Execution Order: Change with arrow controls, then persist with Save Step Order.

• Step Groups: Groups act as execution stages and keep related steps visually organized.

• Run with previous group: Starts a group in the same execution stage as the group above it.

• Execute in Parallel: Applies to an individual step and should only be used when that step has no dependency on sibling work.

• Stop on Failure: When enabled, failure in this step stops task progression.

• Unsaved Changes: Step edits are not active until saved with Save Step.

• Enabled/Disabled: Disabled steps are skipped without deleting configuration.

• Variables: Supported fields can use {{ VariableName }}. Later steps can consume variables created by earlier completed steps.

Always save each edited step before running, save step order after reordering, and only run groups together when their steps do not depend on each other.