Custom Parameters
Custom Parameters let you define reusable task inputs once and link them to one or many automation tasks. This makes task execution flexible without changing step definitions every time.
Where to Manage Parameters
1. Open Operations > Automation.
2. Go to the Parameters tab.
3. Create, edit, and delete parameter definitions from the Custom Parameters table.
Core Parameter Fields
Each parameter definition includes:
• Name - technical parameter name used for script/runbook matching.
• Display Title - friendly label shown to users at execution time.
• Description - helper guidance shown with input controls.
• Mandatory - whether users must provide a value.
• Display Position - base ordering metadata for the parameter definition.
• Parameter Type - controls the input model and available configuration.
Supported Parameter Types
Current parameter types available in create/edit dialogs:
• String - free text input with optional default value.
• Password - sensitive text input with encrypted storage and password-style entry.
• Int - numeric input with optional default value.
• Bool - true/false switch with optional default.
• DateTime - date/time input value.
• Dropdown - user selects from configured value list.
• Graph Resources - dynamic dropdown populated by Azure Resource Graph query results.
• Known - mapped to built-in known parameter behavior.
• Integration - live choices from a supported Active Directory, Entra ID or Micetro IPAM integration; not every execution integration provides parameter lookups.
• Entra Users - search and select Entra users from a configured Entra ID integration.
• Entra Groups - search and select Entra groups from a configured Entra ID integration.
Known Parameters
Known parameters provide standardized, built-in value sources (for example cloud resource selectors).
• SubscriptionId, SubscriptionName
• VirtualMachineId, VirtualMachineName
• ResourceGroupId, ResourceGroupName
• VirtualNetworkId, VirtualNetworkName
• AzureLocation, ComputeResourceSKU
• LoggedInUser
Graph Resource Parameters
Graph Resource parameters are dynamic and query-driven using Azure Resource Graph, not Microsoft Graph. For directory users/groups, use the Entra or Active Directory selectors instead. Choose a readable display property and a value property matching the receiving step, such as a VM resource ID rather than its display name.
Delegated lookup uses the signed-in user's credentials. System lookup uses the configured Automation application and its Azure permissions. App-only agents cannot assume delegated credentials; use the intended authorized lookup mode, not an identity switch to bypass an access denial.
• Enter a Resource Graph query and use Test Query.
• Review returned resources in test results.
• Set Value Property and Display Property mappings.
• Save the parameter and link it to tasks that need dynamic cloud resource selection.
Integration Parameters
Integration parameters let users select values from connected systems instead of typing them manually. This is useful when a task should target an object from an integration, such as an Active Directory user, Entra user, group, or organizational unit. Micetro IPAM selectors can provide ranges or IP records; record selection needs a parent range. Choose the returned value to match the consuming step, and use a friendly label for display. Supported directory/integration inputs can allow multiple selections if the consuming step accepts them.
For Entra Users and Entra Groups parameters, lookups use your configured Entra ID integration. If you choose Agent identity, keep that selected agent connected so users can search the directory. See Entra ID Integration for setup and permission checks.
• Select the integration source and the value field that should be passed into the task.
• Use a readable display field so users can recognize the right object before execution.
• Link the parameter to a task, then reference it from step fields with {{ ParameterName }}.
Example: select allowed computers for a gMSA
Replace a manually typed computer list with a searchable, multiple-selection input backed by your Active Directory integration. Users select friendly computer names; the task receives the exact account identities expected by the script.
| Setting | Example configuration |
|---|---|
| Name / title | AllowedComputers / Allowed computers |
| Parameter type | Integration → Active Directory; select your enabled directory connection. |
| Object type / selection | Computer / Multiple |
| Value / display field | SamAccountName / Name, if the script accepts computer account names including the trailing $. |
| Custom input | Disabled when users should select directory results. |
| Separator | Choose one that the receiving script explicitly parses. Multiple selections become a joined runtime string. |
| Required | Optional only if the script deliberately supports creation without assigning any new computers. |
Preview the lookup, link the parameter to the task, and bind the script's AllowedComputers input to {{ AllowedComputers }}. Check the actual script before changing its input format: an FQDN, display name, account name, GUID and distinguished name are different values. For distinguished names, use a compatible separator such as a newline; commas already occur inside each distinguished name. Empty optional inputs should produce an empty selection, and existing group members should remain unless removal was explicitly requested.
Optional account and retrieval-group OU inputs can use OrganizationalUnit selectors returning DistinguishedName. The lookup search base limits which choices appear; it does not set the provisioning OU. The lookup connection also does not change the script's execution machine or identity. That execution identity still needs the required directory permissions.
After changing the script's inputs, save a new script version and verify the task's selected version, parameter bindings and defaults. Validate the saved task before an authorized run. Static validation does not prove gMSA provisioning or host readiness; host installation and Test-ADServiceAccount are separate checks.
MCP agents can discover each connection's parameterLookup capabilities and consult get_workflow_guidance with topic automation-parameters. See Microsoft's Get-ADComputer identity reference when matching the script's input contract.
Linking Parameters to Tasks
Parameters become active for task execution when linked in task configuration.
How Linking Works
• Open an automation task and go to linked parameter management.
• Use Link Parameter to select from unlinked custom parameters.
• Configure per-task overrides: display order, required override, and default value override.
• Save link order separately when reordering linked parameters.
Grouping and Discovery Modes
The parameter table supports three working modes:
• All Parameters - full inventory with type, mandatory status, linked tasks, and search.
• Group by Task - parameters organized per task, including shared-parameter visibility.
• Standalone Only - parameters not linked to any task.
Execution-Time Behavior
When a task is executed, linked parameters are prompted in the execution dialog.
• Parameter prompts follow the linked-parameter display order for that task.
• Required parameters are validated before execution is allowed.
• Provided values are passed to task execution by parameter name.
• Execution details show step output and errors for troubleshooting parameter-related failures.
Editing and Deletion Safety
• Editing a parameter updates that shared definition.
• Delete flow warns when a parameter is linked to one or more tasks.
• Removing a parameter can break task assumptions if steps/scripts still expect that input.
Best Practices
• Keep Name stable and script-aligned; use Title for user readability.
• Prefer Dropdown/Known/GraphResources when you want to reduce invalid free-text input.
• Use clear descriptions so operators understand expected format and impact.
• Review standalone parameters periodically and remove unused definitions.