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

• Active Directory Action

• SCOM Maintenance Mode

Certificate-Only Step Types

• Azure Application Gateway

• Azure Key Vault (certificate target)

• Certificate Install

• Citrix ADC / NetScaler Certificate

• Application Proxy 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.

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

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 Step

Creates, updates, or closes a TOPdesk incident using a configured TOPdesk integration.

Required: TOPdesk integration + operation-specific incident fields

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

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

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

• Step-scoped variables are also available for tasks that create more than one incident 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.

SCOM Maintenance Mode Step

Starts or stops SCOM maintenance mode through an AZExecute agent.

Required: SCOM integration + target object + operation

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

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.

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