Variables

Ordyn has two variable layers that admins use in different places:

• persistent variables, which belong to the variable catalog and can be overridden by scope
• runtime job variables, which exist only for one endpoint target during one job run

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.

Secret variable definitions store a selected secret instead of a plaintext default value. The UI shows whether a secret is configured, but it does not reveal the current secret value.

Variable overrides

Overrides let you replace a definition’s default value for a specific scope.

Ordyn supports these override scopes:

• global
• tenant
• folder
• group
• endpoint
• product
• package

More specific scopes override broader ones. For an endpoint, Ordyn resolves variables through tenant, folder ancestry, group memberships, and then the endpoint itself. For packages, it resolves through tenant, product, and package scope.

Group overrides can also use priority when more than one group override applies to the same definition.

The Variables page shows the current definition, any active override, and the effective value after scope resolution.

For secret variables, overrides also point to selected secrets. Ordyn hides the effective plaintext value in the Variables UI. The value is resolved only at runtime when a job, package workflow, or another supported runtime needs it.

Condition editors can also check override state without reading the value itself. Use this when the workflow should behave differently because a value was customized for the endpoint, tenant, folder, or group.

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, including tenant, folder, group, or endpoint overrides.

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.

Firmware password

hardware.firmware.password is a built-in secret variable used to authorize 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 parameters when editing a job template, and common runtime references.

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
• collector["collector-id"].field for stored collector values
• loop.* inside loop bodies

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

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.

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

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.

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 the webhook.
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:

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 a scope-specific value should win for a tenant, folder, group, endpoint, product, or package.
• 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