Ordyn

Appearance

Jobs ​

Jobs are Ordyn's main automation feature.

A job lets you define one reusable workflow and run it against endpoints or once as infrastructure work. Endpoint jobs can be launched manually, assigned to scopes, triggered by schedules or endpoint events, and called from another job. Infrastructure jobs can be launched manually, scheduled, started after another infrastructure job completes, triggered by a webhook, or used to coordinate endpoint child jobs.

For the scheduling and event side of jobs, see Automations. For the complete Runner-backed workflow, see Infrastructure Jobs.

What a job is ​

A job has two parts:

  • a job definition, which is the authored workflow template
  • one or more job runs, which are concrete executions of that template

Every job has an execution scope:

  • Endpoint creates one job target for each resolved endpoint.
  • Infrastructure creates one job target for the run and does not select endpoints.

For endpoint jobs:

  • endpoint A can already be on a later step while endpoint B is still on an earlier step
  • each endpoint gets its own task results, variables, and failure state
  • later steps can branch differently per endpoint based on what actually happened on that machine

Infrastructure jobs are intended for Runner work that should execute once, such as a build or an environment-wide administration script.

The execution scope is fixed when the job is created. Endpoint jobs and infrastructure jobs live in separate libraries and folder trees.

Where jobs appear in the UI ​

Jobs are split into two libraries under Operations:

  • Endpoint Jobs contains jobs that run independently for one or more endpoints.
  • Infrastructure Jobs contains jobs that run once on a reserved Runner.

Each library covers:

  • the job definition list
  • job create and edit pages
  • job detail pages
  • job folders for organizing definitions

Jobs also show up in other places:

  • endpoint Jobs tab
  • group Jobs tab
  • tenant trigger rules and schedules
  • Reporting > Job Runs
  • package and OS image workflow expansion when those features generate job tasks under the hood

Reusable Job Templates are a separate entry under Operations. Multi-stage rollouts are authored directly in endpoint or infrastructure jobs with composition tasks.

What a job can do ​

A job is an ordered tree of tasks.

Endpoint jobs can use the full endpoint task catalog. Infrastructure jobs use a focused Runner task catalog that includes:

  • inline Bash, POSIX shell, or PowerShell scripts
  • saved Runner scripts
  • Windows PE image builds
  • delays, log messages, email, and job variables
  • branches and loops

For the editor-visible task catalog, see Available Tasks.

In practice this lets jobs cover things like:

  • restart a service or kill a process
  • read, write, retrieve, or place files
  • inspect or change the Windows registry
  • run a saved script and use its structured JSON result later in the workflow
  • install or update approved packages
  • branch based on live endpoint state or earlier task results
  • prepare for interactive Windows tasks that need the logged-in user to confirm or postpone

How Targeting Works ​

Endpoint jobs can be run against endpoints resolved from different scopes.

Typical targeting paths are:

  • immediate manual run against selected endpoints
  • assignments inherited from tenant, folder, or group scope
  • schedules
  • endpoint trigger rules
  • child runs launched by a Run endpoint job task

The resolved endpoint set is turned into per-endpoint execution state. Ordyn then dispatches tasks to each target independently.

Infrastructure jobs run once and do not accept endpoint assignments or endpoint targets. Select one Runner pool in every infrastructure job's overview. Infrastructure schedules also run once and do not wait for endpoint connections.

Endpoint-scoped Runner tasks keep the endpoint as the job target and resolve the execution pool from that endpoint's Runner pool assignments. Every Runner-backed step for one target uses the same reserved Runner. See Runners for pool assignment precedence, capacity, and Runner selection.

For infrastructure jobs, the first Runner-backed step reserves one compatible Runner from the selected pool. The same Runner and workspace are used for every Runner-backed step in the complete run. See Infrastructure Jobs.

Authoring model ​

When you create or edit a job, you are primarily working with:

  • task order
  • task configuration
  • branch and loop structure
  • validity windows

Endpoint jobs also provide endpoint targeting, desktop execution, user interaction, shutdown, and self-service settings.

Validity windows ​

Validity windows restrict when Ordyn may start a job.

When no validity windows are configured, the job can start at any time. When one or more windows are configured, Ordyn starts new job runs only when the current server time falls inside one of those windows.

This applies to every path that creates a new job run:

  • immediate manual run
  • schedules
  • endpoint trigger rules
  • infrastructure completion automations
  • infrastructure webhook automations
  • pending scheduled endpoints that become ready later

Validity windows gate job start time only. They do not stop or pause a job run that has already started.

Each window contains:

  • one or more weekdays
  • a start time
  • an end time

Times use 24-hour HH:MM values in five-minute increments. The start time is inclusive and the end time is exclusive, so a 08:00 to 18:00 window allows starts at 08:00 and rejects starts at 18:00. 24:00 is allowed as an end time for windows that run until the end of the day.

Windows cannot overlap on the same weekday. Adjacent windows are allowed, for example 08:00-12:00 and 12:00-18:00.

Validity windows currently use server time. If endpoint-local or tenant-local scheduling is needed, configure the windows in the server timezone.

Endpoint requirements ​

Endpoint requirements are checked once when an endpoint target becomes available to start. When a target does not meet a requirement, Ordyn marks the target and its unexecuted steps as Skipped. The target carries a warning and shows the requirement reason.

The final run status depends on all targets:

  • If at least one target succeeds and every other target is skipped by requirements, the run is Succeeded with warnings.
  • If every target is skipped by requirements, the run is Failed because no requested work ran.
  • A failed, timed-out, or aborted target keeps its normal terminal precedence and cannot be hidden by skipped or successful targets.

These rules apply to manual, scheduled, automated, nested, and self-service job runs.

Step error behavior ​

Each configurable step has an Error behavior setting:

  • Stop and fail marks the step failed, timed out, or aborted; prevents later steps in the job from running for that endpoint; and keeps the failure as the final job result.
  • Continue and fail keeps the failed, timed-out, or aborted step visible, allows later steps in the job to run, and keeps the original failure as the final job result.
  • Continue and allow success keeps the failed, timed-out, or aborted step visible, allows later steps in the job to run, and permits a final job result of Succeeded with warnings when no other step causes a blocking failure.

Succeeded with warnings is a successful status. Success-based job triggers run normally, while the warning marker shows that at least one step used Continue and allow success after an error.

Control steps whose execution behavior is fixed show Built-in behavior instead of this selector.

Automatic reboot steps inherit the error behavior of the step that requested reboot handling. If an automatic reboot, disconnect, reconnect, boot-change, readiness, or rerun step fails, Ordyn skips the remaining automatic steps in that reboot sequence and shows the failure on the originating step. The selected error behavior then determines whether later steps in the job may run and whether the final job result can be Succeeded with warnings.

Timeout ​

Each job definition also has a target timeout.

Ordyn applies that timeout to every target in the run. An endpoint job has one target per endpoint; an infrastructure job has one infrastructure target. In the editor, this is the Timeout field on the job overview.

When a target runs past its timeout, Ordyn marks that target as timed out and stops the remaining work for that endpoint. The current default is 86400 seconds, and the editor enforces a minimum of 60 seconds.

The target timeout is the outer execution budget for that endpoint. Individual steps can still have their own timeout. If a step has an explicit timeout, Ordyn uses that step timeout for the instruction sent to the endpoint or preboot agent. If a normal instruction step has no explicit timeout, Ordyn uses the platform instruction TTL, which defaults to 300 seconds.

File-staging steps have a longer default because they can transfer large package files, archives, or OS images. If no explicit step timeout is configured, Ordyn gives file staging 14400 seconds by default. An active transfer can continue for up to 28800 seconds. If an explicit timeout is configured on the step, that explicit timeout remains the hard limit.

If an endpoint reboot interrupts file staging, staged package extraction, or a Windows desktop-readiness wait, Ordyn retries that preparation step after the agent reconnects. Recovery is limited to three attempts within 30 minutes. Other interrupted steps use their normal failure behavior.

Install Windows updates and Install approved Windows updates use the normal instruction timeout. Configure an explicit step timeout when Windows Update may need longer than the platform instruction TTL. If the timeout expires before the agent reports a terminal result, Ordyn times out the step and requests cancellation. Windows servicing work that Windows has already accepted may continue independently.

Generated WinPE installer workflow steps are handled differently. When an Install OS image task expands an OS image install workflow and a generated WinPE step has no explicit timeout, Ordyn gives that instruction the remaining target timeout budget instead of the default 300 seconds. This lets long-running Windows Setup commands continue while still keeping the endpoint target bounded by the job timeout. Ordyn keeps at least a small final dispatch budget when the target is already close to its deadline.

The target timeout is always terminal and is not changed by a step's error behavior. If a PXE or WinPE installation reports success after the endpoint target has already timed out, Ordyn keeps the target timed out and does not revive or continue the remaining steps. For OS deployment jobs, set the job timeout long enough to cover PXE boot, WinPE preparation, Windows Setup, reboot, enrollment, instruction readiness, and Windows desktop readiness.

Durable Result Spooling ​

Jobs can enable durable result spooling from the job overview.

This is intended for maintenance jobs where a supported step may restart the Ordyn agent service or temporarily interrupt Ordyn connectivity before the step result can be reported. When enabled, Ordyn sends supported endpoint steps with a durable-spooling request and waits until the configured spooling timeout for the result to arrive.

Supported steps:

  • Run inline script
  • Run endpoint script
  • Install APT updates
  • Install Windows updates
  • Install approved Windows updates

For APT update steps, Ordyn automatically enables durable result spooling when the target endpoint is marked in Edit endpoint as an Ordyn server host, Ordyn edge host, or Ordyn hypervisor host. This does not require the job-level durable spooling option.

Platform behavior:

  • Linux agents use systemd-run to hand the step to a short-lived detached runner.
  • If systemd-run is unavailable or rejects the handoff, the step fails instead of falling back to a plain child process.
  • Windows agents can store the completed result locally and retry delivery while the configured recovery window remains active. Durable result spooling does not make arbitrary running Windows processes survive an Ordyn agent service restart.

Caveats:

  • This is not a general retry mechanism. It does not rerun a failed step.
  • It is designed for agent-service restarts and temporary Ordyn connectivity loss after the step has started.
  • OS reboots do not replay arbitrary unfinished scripts after boot. Generated downloads, staged package extraction, and Windows desktop-readiness waits can be retried as safe preparation steps after replay synchronization.
  • If the endpoint target timeout expires before the spooled result is reconciled, the job target can still time out.
  • Keep the spooling timeout long enough for the expected maintenance window, but short enough that genuinely lost results fail in a useful time.

Desktop execution ​

Some jobs need an interactive Windows desktop instead of just a background service context. Package workflows cover that behavior in detail, including the generated GUI replay steps and the desktop session handling around them.

Jobs can also run Replay GUI automation directly. By default that task manages desktop preparation itself: it waits for Windows desktop readiness, inspects the console session, logs on a managed desktop account if needed, locks input, runs the replay, and performs cleanup. Disable managed preparation only when the job explicitly contains the desktop-control steps itself. Do not set desktop execution to not required for jobs that contain GUI replay or manual desktop-control steps. Replay GUI automation is not supported inside For each or While loop bodies.

The manual desktop-control steps are:

  • Wait for Windows desktop readiness
  • Inspect desktop session
  • Desktop logon
  • Lock desktop input
  • Unlock desktop input
  • Desktop logoff

When admins use these steps manually, they own the cleanup. A manual Lock desktop input needs a matching Unlock desktop input, and a manual managed Desktop logon needs a matching Desktop logoff unless the job intentionally leaves that desktop session active. Cleanup steps should use conditions that still run after failures.

When a desktop logon creates a managed session, Ordyn preserves the Windows sign-in identity selected before the task. Windows policies that hide the last signed-in user continue to control what the sign-in screen displays.

For the full editor-visible catalog, see Available Tasks. See Packages for the package workflow step catalog and package GUI replay details.

User interaction ​

Jobs can also declare how user-facing prompts behave for supported Windows tasks.

That includes settings such as:

  • notify logged-in user
  • require confirmation
  • countdown seconds
  • postpone durations

This is how update or disruptive tasks can be made user-aware without turning the whole job into an ad hoc manual process.

Variables and branching ​

Jobs support runtime variables and explicit branching. For the full variable model and templating rules, see Variables.

Job variables ​

Use the saved job's Variables tab to select custom variable definitions, set a job override, and enable Prompt for an optional run-specific override. Infrastructure jobs also inherit overrides from their infrastructure-folder ancestry.

Resolved values are available through vars.*. Interactive launches can submit run-specific overrides, while automated starts use persistent values. An unresolved variable has the value null, which job conditions can handle explicitly. See Job Variables for resolution, self-service, secret handling, and run snapshots.

Runtime job variables ​

Use Set job variable when a later step needs a named runtime value.

Those values live under job.vars.* and are scoped to the current endpoint target only.

Branching ​

Use an if task when a job step should depend on a previous outcome.

This is the usual pattern when you need to:

  • stop only on specific failures
  • continue if a process was already absent
  • branch based on a script's structured JSON output
  • react differently per endpoint based on current state

Files, scripts, and templates ​

Jobs can combine saved scripts, runtime variables, and templated payload fields.

Examples:

  • run a script that returns JSON
  • store one field as job.vars.generated.config
  • write that value into a file with {{ job.vars.generated.config }}

This makes jobs the main place where Ordyn turns collected data, script output, and managed artifacts into real endpoint actions.

Windows endpoint scripts and package-backed tasks can run under different Windows identities. See Windows Execution Contexts for the supported modes and their tradeoffs.

Exporting And Importing Jobs ​

Open a job's actions menu to export it:

  • Export JSON downloads the versioned job definition immediately. It contains resource IDs but does not include dependencies.
  • Export complete job builds an Ordyn job bundle in the background and starts the download when the bundle is ready.

A complete job bundle includes saved scripts, collectors and their scripts, global managed files used directly or through folder-sync steps, referenced persistent variable definitions, and the self-service icon. Packages and other environment-specific resources remain external references.

Generated complete-job exports are removed after 24 hours. Treat them as sensitive configuration artifacts because they can contain script source and managed file contents.

Use Library > Import to upload either format. Bundle import reviews dependency-name conflicts and asks for a Files destination and other missing data before it creates anything.

Imported complete jobs are standalone definitions. Their source template link, assignments, schedules, triggers, run history, and audit history are not transferred. See Import for the dependency and review model, or Complete Job Bundle Format to generate a portable archive outside Ordyn.

Job templates ​

Job templates let admins create reusable job blueprints with configurable inputs.

Use a template when several jobs should share the same task tree but differ by values such as service name, Docker image list, compose file, base path, or tag. A template has endpoint or infrastructure execution scope. Linked endpoint jobs support normal endpoint assignments, composition tasks, and self-service; linked infrastructure jobs use the template's Runner pool and infrastructure automations. Both scopes retain schedules, run history, and audit information.

Template inputs use template.* references and are expanded when the job is created or synchronized. Normal runtime references such as vars.*, endpoint.*, and steps[...] stay in the resulting job and resolve later during execution.

See Job Templates for the input model, synchronization behavior, and examples.

Job runs and history ​

Every execution of a job becomes a job run with task execution records. Endpoint runs have one target per endpoint. Infrastructure runs have one target for the complete Runner-backed workflow.

Operators can inspect:

  • overall run status
  • endpoint-level progress
  • Runner context for infrastructure jobs
  • task output and errors
  • downloadable artifacts produced by supported tasks
  • history for a specific job definition

This is what makes jobs auditable and repeatable rather than just being transient remote commands.

Endpoint history also records the job and step timeline for each target endpoint. See Audit And History for how global audit, endpoint history, timestamps, and access scope work.

Use Reporting > Job Runs to search and filter endpoint and infrastructure execution history from one page. See Job Runs Reporting.

Disabling jobs on one endpoint ​

Ordyn also supports endpoint-local job disables.

This lets you block one specific job from launching on one specific endpoint without changing the job definition itself or removing higher-level assignments.

It affects future dispatch only. It does not rewrite or cancel runs that already exist.

Self-service jobs ​

Jobs can be marked as self-service enabled so authorized Windows users can run them from the local Ordyn portal without opening the Ordyn web UI.

Self-service does not bypass the normal job model. Ordyn still requires:

  • the job to be self-service enabled
  • the job to be assigned to the target endpoint
  • the signed-in Windows account to be allowed by the endpoint's effective self-service policy
  • source and target endpoints to be in the same tenant

The portal run scope controls whether a self-service request starts the job only on the triggering endpoint or starts one grouped run across all eligible assigned endpoints visible to the signed-in Windows account.

See Self-Service Portal for the full authorization flow, policy inheritance model, audit data, and threat model.

Composing jobs ​

Use Run endpoint job to call a reusable endpoint job as one step in a larger workflow. The step can target the current endpoint, one or more endpoint groups, or endpoint IDs produced by an expression. It waits for the child run to finish before the parent continues.

Use Wait for endpoint set state when the next stage must wait until every endpoint in a resolved set reaches a selected relay state. Both tasks snapshot their endpoint set when the step begins.

Together these tasks support ordered rollout stages, per-stage target selection, child-run concurrency, readiness gates, child-job variable resolution, and the normal step error behavior. See Composing Jobs.

Use this page as the feature overview.

For lower-level behavior and detailed reference, see: