Variables

Ordyn has two variable layers:

• persistent variables, which belong to the shared variable catalog and resolve through the scopes that apply to the current operation
• runtime job variables, which exist only for one target during one job run

Persistent variables use vars.*. Runtime job variables use job.vars.*. The same templating system can read both.

Variable definitions

Variable definitions are the reusable records you manage in the Variables area of the UI.

Each definition has:

• a key
• a label
• an optional description
• a kind, either system or custom
• a value type, either string, number, boolean, or json
• an optional secret flag
• an optional folder
• a default value

Use system for built-in values Ordyn provides and custom for values you define yourself.

Super administrators can edit the default value of a system variable from the Variables page. Its key, label, type, folder, description, and secret behavior are fixed by Ordyn. Tenant and endpoint administrators can continue to set scoped overrides where their permissions allow it.

Secret variable definitions store their value encrypted. Enter the value directly when creating a definition; when editing, leave the field blank to preserve the current value or use the clear option to remove it. Secret values remain redacted.

A secret can optionally be marked Retrievable. Retrievable secrets remain hidden by default, but admins can reveal them. Every reveal is audited. Leave this disabled for credentials that Ordyn only needs to resolve internally, such as registry credentials.

String values can contain multiple lines, including PEM-encoded certificates and keys. String fields grow as lines are added. For a secret, select Multiline before entering multiple lines; pasting multiline text switches the editor automatically. Browser entry normalizes CRLF and CR line endings to LF while preserving a trailing newline. Literal \n text remains literal. Encode the complete value, for example with Base64, when a script requires byte-for-byte line-ending preservation, then decode it inside the script.

Scope and inheritance

Every persistent variable starts with its definition default. An applicable override replaces the value from every broader scope. The exact scopes depend on where Ordyn is resolving the variable.

Source	Where it applies
Definition default	Every context in which the definition is available.
Tenant	Endpoints in that tenant.
Endpoint folder	Endpoints in that folder and its descendant folders. Parent folders resolve before child folders.
Group	Endpoints that belong to the group. Group priority decides between matching groups.
Endpoint	That endpoint.
Product	The software product and endpoint tasks using it
Package	The package and endpoint tasks using it. A package inherits from its product.
Infrastructure job folder	Infrastructure jobs in that folder and its descendant folders. Parent folders resolve before child folders.
Job	Runs of that saved job.
Submitted run value	The selected target or targets in the run being started. Only prompt-enabled job variables accept submitted values.

Endpoint folders participate only in endpoint inheritance, and infrastructure job folders participate only in infrastructure-job inheritance. Endpoint-job folders, group folders, package folders, and variable-definition folders are organizational and don't override variables.

Endpoint job resolution

An endpoint task resolves the complete applicable chain in this order:

Definition default
→ endpoint tenant
→ endpoint folder ancestry
→ winning endpoint group
→ endpoint
→ task product
→ task package
→ job
→ submitted run value

An ordinary task skips the product and package layers and proceeds from the endpoint to the job and submitted value. A product task adds its product. A package task adds the package's product and then the package. This means a package value can override an endpoint value for that package task without affecting ordinary tasks in the same job.

The endpoint, product, and package layers remain live while an endpoint run is active. The job value and submitted run value are frozen when the run is created.

Infrastructure job resolution

Infrastructure jobs resolve custom definitions in this order:

Definition default
→ infrastructure job folder ancestry
→ job
→ submitted run value

The complete result is frozen when the run is created. Later changes to a definition default, folder override, or job override do not alter that run. See Job Variables for prompts and run behavior.

Product and package resolution

Outside an endpoint job, a product resolves the definition default and its product override. A package resolves the definition default, its product override, and its package override.

Matching groups

When an endpoint belongs to several groups with an override for the same definition, the override with the highest priority wins. If two or more matching groups share the highest priority, the group layer is ambiguous. The UI lists the conflicting groups, and Ordyn does not expose that variable to the task. Add a more specific endpoint, product, package, job, or submitted run value, or assign distinct group priorities, to resolve the conflict.

Null values and removal

An explicit null at a more specific scope masks values from broader scopes and is exposed to the job as an unresolved value. Removing the override removes the mask and restores normal inheritance.

Variable table views

The Variables table provides these views:

• Configured shows definitions configured directly on the selected scope. On a job, a Prompt setting also counts as direct configuration.
• Effective shows direct configuration, inherited or default values, and unresolved group conflicts.
• All variables shows every definition eligible for that scope, including definitions with no configured value.

On an endpoint job, the table labels the displayed value as Job default. The job default combines the definition default and any direct job override. Tenant, endpoint folder, matching group, endpoint, product, and package values are resolved for each target and task when the job runs and are not displayed as part of the saved job default.

For secret variables, enter the override value directly. Ordyn hides override and effective plaintext values by default. Authorized administrators can use the explicit Reveal action for retrievable secrets at the current scope; that reveal is audited and remains only in the current page until it is hidden or refreshed. Leaving the value blank while editing preserves it; clearing it removes that scoped value.

Saved-script secret parameters, Windows Account passwords, templated-user passwords, container registries, and secret-valued settings select secret variable definitions. A Windows Account username can use any string variable. A templated-user username requires a plain string variable so the sign-in identity remains available as ordinary task configuration while its password stays secret.

Condition editors can also check override state without reading the value itself. You may use this when the workflow should behave differently because a value was customized.

Two override checks are available:

• Direct endpoint override is true only when the current endpoint has its own endpoint-scoped override for the selected variable.
• Effective override is true when the selected variable resolves from any non-default override that applies to the current endpoint.

These checks are evaluated for the endpoint target running the job. They do not check product or package overrides unless the runtime context explicitly targets package workflow variable resolution.

Built-in credential variables

Ordyn provides these retrievable secret system variables for device credentials:

• hardware.firmware.password
• hardware.intel_amt.admin_password
• hardware.intel_amt.mebx_password
• windows.local_admin_password

Their values are encrypted and redacted by default. Authorized administrators can reveal a value from the Variables page; every reveal is audited. Configure a global default only when devices share a credential and use overrides where credentials differ.

windows.local_admin_username is a non-secret system variable. Its default is OrdynAdmin; a super administrator can edit that default from the Variables page.

Firmware password

hardware.firmware.password is a built-in secret variable that authorizes firmware-setting remediation on password-protected devices.

Configure it with the device's existing Dell Admin or BIOS setup password. The value is resolved through the normal endpoint variable precedence, so you can configure a shared secret at a broader scope and add endpoint overrides for devices with different passwords.

The password is used only when a Firmware / BIOS Policy remediation finds drift and the device reports that an Admin BIOS password is set. Audit-only runs do not use it. If the device has no Admin BIOS password, a configured value is ignored.

A missing or incorrect value causes protected remediation to report an error. This variable does not define a desired password and does not set, rotate, or clear the BIOS password.

Runtime job variables

Set job variable stores a runtime value under job.vars.<name> for the current endpoint target only.

These values are not shared across endpoints, and they do not persist after the run ends. Use them when one step computes a value that later steps or branches need to reuse.

Templating

Fields that support templating accept {{ ... }} placeholders.

Use template fields when you want Ordyn to resolve values during execution inside otherwise literal text. If the whole field is one template expression, Ordyn preserves the resolved scalar type. If you mix literal text and template expressions, Ordyn turns the result into text.

In the frontend, templated fields offer inline autocomplete after typing {{. Autocomplete suggests persistent variables, template inputs when editing a job template, earlier reachable task results, active loop values, runtime job variables, and common runtime references. Suggestions are scoped to the current job and field. Infrastructure jobs omit endpoint-only, collector, and endpoint variable-override references; trigger labels identify the event source that supplies each value.

Common template sources include:

• vars.* for persistent variables
• job.vars.* for runtime job variables
• steps["step-id"].result.* for earlier task results
• endpoint.* for endpoint context
• trigger.* for the event or action that started the job run
• job.run.* for current run metadata
• job.workspace for the absolute shared workspace path in supported endpoint and infrastructure job fields
• collector["collector-id"].field for stored collector values
• loop.* inside loop bodies

Common endpoint context fields include endpoint.id, endpoint.kind, endpoint.hostname, endpoint.fqdn, endpoint.tenant_id, and endpoint.primary_ip_address. The primary address comes from the endpoint's primary network interface and is null when no primary address is available.

Missing template paths fail the task instead of resolving as empty text.

For endpoint jobs, {{ job.workspace }} resolves to the workspace shared by all tasks for that endpoint target. Endpoint scripts and package commands use this directory as their default working directory. Each endpoint target has a separate workspace, and Ordyn removes it after the target finishes.

For infrastructure jobs, {{ job.workspace }} resolves to the reserved Runner's host workspace path. In Docker execution it resolves to the job's configured container workspace path. Use it in inline Runner script content, executable paths and arguments, string parameters, environment values, and rendered staged-file content. Runner working directories, file-placement destinations, Git checkout destinations, and artifact paths remain workspace-relative and do not accept this reference.

Saved Runner script content is executed verbatim. Use ORDYN_WORKSPACE in the script or pass the workspace through a string parameter.

When a templated endpoint instruction references a secret variable, Ordyn resolves the plaintext value for execution and sends it to the endpoint agent as a redaction token. Exact matches are redacted from agent stdout, stderr, operational command-output logs, and audit command invocation logs. The rendered value is still available to the running script or command by design.

Endpoint infrastructure roles

Endpoint jobs can read the infrastructure roles configured in Edit endpoint:

Variable	Type	Meaning
endpoint.infrastructure_roles.ordyn_server_host	boolean	Whether the endpoint is marked as an Ordyn server host.
endpoint.infrastructure_roles.ordyn_edge_host	boolean	Whether the endpoint is marked as an Ordyn edge host.
endpoint.infrastructure_roles.ordyn_hypervisor_host	boolean	Whether the endpoint is marked as an Ordyn hypervisor host.
endpoint.infrastructure_roles.edge_service_id	string or null	Assigned Edge service ID for an Ordyn edge host, or null when no Edge service applies.

These fields are available as Endpoint field references in the guided If branch editor.

The equivalent raw condition is:

endpoint.infrastructure_roles.ordyn_server_host == true

Role variables describe the job target endpoint even when another supported task uses a fixed execution endpoint.

Expressions

Some fields use raw expressions instead of {{ ... }} placeholders.

That is the case for:

• condition editors
• Set job variable
• Set variable override

In those fields, write the expression directly, for example:

• endpoint.primary_user
• vars.site_code
• job.vars.selected_site
• job.run.total_steps
• steps["check"].result.outcome
• vars.registry.token

Secret variable expressions in Set job variable and Set variable override are not just display references. They resolve to the real value and store that value in the selected runtime variable or persistent override path. Prefer passing the secret variable directly to the task that needs it instead of copying the plaintext into another variable unless that storage is intentional.

Advanced expressions

Advanced expressions can reference:

• earlier task results through steps["<step-id>"]
• persistent inherited variables through vars.<name>
• built-in endpoint context through endpoint.<field>
• job run trigger details through trigger.<field>
• explicit runtime job variables through job.vars.<name>
• current run metadata through job.run.<field>

The same authored reference model is used by jobs, package workflows, and OS image workflows so branching logic behaves consistently across editors.

Examples:

• steps["task-id"].result.outcome == "terminated"
• steps["task-id"].result.reboot_required == true
• steps["task-id"].result.is_installed == false
• steps["task-id"].result.found == true
• steps["task-id"].result.updated_key_count == 1
• vars.site_code == "BER" || vars.site_code == "MUC"
• endpoint.system.battery_charge_percent >= 50
• trigger.type == "self_service"
• trigger.self_service.windows_account == "ACME\\alex"
• job.vars.install_state == "ready"
• job.run.total_steps > 4
• steps["task-id"].status == "succeeded" && vars.process_state != "failed"
• contains(vars.site_code, "BER")
• !contains(vars.site_code, "TEST")
• is_empty(vars.maintenance_window)
• !is_empty(job.vars.detected_version)
• has_endpoint_variable_override("vars.site_code", "direct_endpoint") == true
• has_endpoint_variable_override("vars.site_code", "effective") == false

Use a Set job variable step when you want to store a runtime value for later job steps or branches. That step writes into job.vars.*.

Supported operators:

• ==
• !=
• >
• >=
• <
• <=
• &&
• ||
• parentheses for grouping

String values additionally support:

• contains(value, needle)
• !contains(value, needle)
• is_empty(value)
• !is_empty(value)

Array values support exact membership checks:

• contains(vars.allowed_paths, "/opt/ordyn-api")
• !contains(vars.ignored_paths, loop.vars.compose_project.working_dir)

In the visual condition editor these appear as contains, does not contain, is empty, and is not empty for string sources. Empty-string checks should use is empty / is not empty; do not rely on comparing against "" in the guided editor.

Variable override checks use:

has_endpoint_variable_override("vars.<variable-key>", "direct_endpoint")
has_endpoint_variable_override("vars.<variable-key>", "effective")

The first argument must be a persistent variable reference under vars.*. The second argument must be either direct_endpoint or effective.

Runtime references

The guided UI supports these reference sources:

• prior task status
• prior task error message
• normalized result fields for supported task kinds
• latest stored collector values from the current endpoint
• persistent variables from the variable catalog
• built-in endpoint fields
• trigger fields through trigger.*
• runtime job variables from earlier Set job variable steps
• current job run metadata through job.run.*

In the guided builder these are split into separate source kinds:

• Collector value for the latest stored value of a collector field on the current endpoint
• Variable for persistent catalog variables
• Variable override state for checking whether a persistent variable is directly or effectively overridden for the current endpoint
• Endpoint field for endpoint.*
• Trigger field for trigger.*
• Job variable for job.vars.*
• Job run field for job.run.*

Collector values compile to raw expressions like:

collector["collector-id"].battery_charge_percent >= 80

Use Task result instead when you want the output of a previous Run collector step in the same job rather than the endpoint's latest stored collector state.

Trigger variables

Every job run target receives trigger details under trigger.*.

Common fields:

Variable	Meaning
trigger.type	The run origin, such as manual, time, self_service, webhook_received, snmp_trap_received, endpoint_connected, post_enrollment, system_boot, user_logon, user_logoff, job_completed, windows_update_approved, or system_shutdown_requested.
trigger.source	The source category, such as manual, schedule, self_service, webhook, snmp, or automation.
trigger.target_endpoint_id	Endpoint target for this job run target. Infrastructure runs do not provide an endpoint target.

Manual runs can include:

Variable	Meaning
trigger.mode	Manual run mode, such as selected endpoints, assigned endpoints, or scope.
trigger.user.id	User ID that started the run.
trigger.user.name	User display name.
trigger.user.email	User email address.

Time-based runs can include:

Variable	Meaning
trigger.schedule.id	Schedule ID.
trigger.schedule.name	Schedule name.
trigger.schedule.scheduled_for_at	Scheduled run time.
trigger.schedule.deferred	Whether the run waited for an offline endpoint to reconnect.

Windows update approval runs can include:

Variable	Meaning
trigger.windows_update.approval_count	Number of approval events combined into this run.
trigger.windows_update.ring_ids	IDs of enabled Windows update rings involved in the combined event.
trigger.windows_update.approval_sources	Approval sources included in the event, such as manual or automatic.
trigger.windows_update.reasons	Reasons the approvals became active, such as approval or ring_enabled.
trigger.windows_update.first_event_at	Time of the first combined approval event.
trigger.windows_update.last_event_at	Time of the most recent combined approval event.

Self-service runs can include:

Variable	Meaning
trigger.self_service.windows_account	Windows account that requested the run.
trigger.self_service.source_session_id	Windows session ID that launched the portal request. Use it to target self-service user messages and session-scoped process termination.
trigger.self_service.source_endpoint_id	Endpoint where the portal request came from.
trigger.self_service.source_endpoint_hostname	Hostname where the portal request came from.
trigger.self_service.target_endpoint_id	Endpoint selected for the job.
trigger.self_service.target_endpoint_hostname	Hostname selected for the job.
trigger.self_service.target_endpoint_ids	Endpoint IDs included in the self-service run. Multi-device self-service runs include every eligible assigned endpoint.
trigger.self_service.target_endpoint_count	Number of endpoints included in the self-service run.
trigger.self_service.authorization_basis	Policy basis that allowed the request.

Webhook runs can include:

Variable	Meaning
trigger.webhook.event_id	Stored webhook event ID.
trigger.webhook.webhook_id	Webhook definition ID.
trigger.webhook.service_client_id	Webhook service client ID.
trigger.webhook.endpoint_id	Endpoint targeted by an endpoint-scoped webhook. Infrastructure-scoped webhooks leave this value empty.
trigger.webhook.method	HTTP method.
trigger.webhook.source_ip	Resolved caller source IP.
trigger.webhook.content_type	Request content type, when provided.
trigger.webhook.headers	Normalized request headers.
trigger.webhook.query	Query parameters.
trigger.webhook.body	Parsed request body.
trigger.webhook.raw_body	Raw request body text, when present.
trigger.webhook.payload	Full normalized request payload.

SNMP trap runs can include:

When one trap fans out to multiple endpoints, every resulting run receives the same stored trap event and normalized payload.

Variable	Meaning
trigger.snmp.event_id	Stored trap event ID.
trigger.snmp.service_client_id	SNMP service client ID.
trigger.snmp.source_address	Trap source address.
trigger.snmp.source_port	Trap source port.
trigger.snmp.version	SNMP version.
trigger.snmp.auth_identity	Community or SNMPv3 identity.
trigger.snmp.trap_oid	Trap OID.
trigger.snmp.enterprise_oid	Enterprise OID, when present.
trigger.snmp.uptime_ticks	Device uptime ticks from the trap.
trigger.snmp.varbinds	Trap varbind list.
trigger.snmp.payload	Full normalized trap payload.

Windows user logon and logoff runs can include:

Variable	Meaning
trigger.windows_session.event_id	Unique ID of the accepted logon or logoff event.
trigger.windows_session.occurred_at	Time reported by the endpoint agent.
trigger.windows_session.principal	Windows account name, when Windows provides it. This can be empty for logon or logoff events.
trigger.windows_session.session_id	Windows session ID.
trigger.windows_session.is_console	Whether this is the local console session.
trigger.windows_session.is_remote_desktop	Whether this is a Remote Desktop session.

System boot runs can include:

Variable	Meaning
trigger.system_boot.event_id	Unique ID of the detected system boot event.
trigger.system_boot.boot_id	Boot identity reported by the endpoint.
trigger.system_boot.previous_boot_id	Boot identity reported before this boot.
trigger.system_boot.booted_at	Estimated operating-system boot time, based on the report time and uptime when available.
trigger.system_boot.observed_at	Time Ordyn detected the changed boot identity.
trigger.system_boot.uptime_seconds	Endpoint uptime reported when the boot was detected.

Job-completed and shutdown automations can include:

Variable	Meaning
trigger.source_job_run_id	Source job run ID, when another job triggered the run.
trigger.source_job_run_target_id	Source job run target ID, when available.
trigger.shutdown_request_id	Shutdown request ID for shutdown-triggered runs.

For example, process.terminate exposes:

• Outcome
• Matched process count
• Terminated process count

if tasks expose:

• Condition result
• Selected branch

Update-related tasks also expose:

• Reboot required

Service inventory tasks expose:

• Any service restart required
• Restart-required service count

Software product check tasks expose:

• Installed
• Match count
• Detected version

Endpoint connection check tasks expose:

• Connected
• Outcome
• Endpoint ID
• Checked at

Key/value file tasks expose:

• read
  • Found
  • Value
  • Matched key count
  • Format
  • Section
• write
  • Operation
  • Created file
  • Created key count
  • Updated key count
  • Nulled key count
  • Deleted key count
  • Deduplicated key count
  • Matched key count before
  • Value
  • Format
  • Section

Read system status exposes:

• Power source
• Charging state
• Battery present
• Battery charge percent
• Reboot required
• filesystem metrics by mount point or drive letter:
  • Filesystem total bytes
  • Filesystem used bytes
  • Filesystem available bytes
  • Filesystem used percent
  • Filesystem available percent

For filesystem metrics, select the metric and enter a mount point or drive letter such as C:, C:\, /, or /var. Ordyn normalizes that into a stable runtime path like result.filesystems_by_mount.c.used_percent or result.filesystems_by_mount.var.used_percent.

Branching example

process.terminate exposes a normalized runtime result:

• result.outcome
  • terminated
  • not_running
  • failed
• result.matched_process_count
• result.terminated_process_count

That makes the common "terminate if running, otherwise continue" pattern much less brittle than matching free-form stderr text.

One example flow:

1. terminate process AcmeApp.exe
2. add a Set job variable task that stores the task's Outcome as job.vars.process_state
3. add an if task that checks whether job.vars.process_state equals not_running or terminated
4. run uninstall only in the selected then branch

Common patterns

• Use a persistent variable for environment, tenant, or folder defaults.
• Use Set variable override when job logic should set, null, or remove a persistent override for a tenant, endpoint folder, group, or endpoint.
• Use Set job variable when a later step in the same target needs the computed value again.
• Use templated fields for commands, file content, scripts, and other text that should mix literal text with resolved values.

Where to go next

• Available Tasks
• Jobs overview