Jobs

Jobs are Ordyn's main automation feature.

A job lets you define one reusable workflow and run it against one or more endpoints. The same job can be launched manually, assigned to scopes, triggered by schedules or endpoint events, and used inside staged rollout orchestration.

For the scheduling and event side of jobs, see Automations.

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 against resolved endpoints

Ordyn executes jobs per endpoint target, not as one shared global process.

That means:

• 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

Where jobs appear in the UI

Jobs live under Operations > Jobs in the frontend.

That area covers:

• the job definition list
• job create and edit pages
• job detail pages with overview, endpoints, and history tabs
• job folders for organizing definitions

Jobs also show up in other places:

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

Reusable Job Templates and staged Orchestrations are separate entries under Operations. They use their own folder trees so the Jobs menu stays focused on executable job definitions.

What a job can do

A job is an ordered tree of tasks.

Current job task kinds include:

• endpoint instructions
• endpoint scripts
• server scripts
• if branches
• loops
• collectors
• software install and uninstall tasks
• software update tasks
• Windows in-place upgrade tasks
• variable and override actions

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

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 job orchestration stage

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

Authoring model

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

• task order
• task configuration
• branch and loop structure
• validity windows
• desktop execution policy
• user interaction policy

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

Timeout

Each job definition also has a target timeout.

Ordyn applies that timeout to every endpoint target in the run, not to the whole run as one shared timer. 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.

Generated package and OS image download steps have a longer default because they can transfer large files from the assigned cache node. If no explicit step timeout is configured, Ordyn gives those download instructions 14400 seconds by default. While the agent reports valid download progress, Ordyn refreshes the instruction expiry so slow but active downloads can continue, capped at 28800 seconds from the original issue time. If an explicit timeout is configured on the step, that explicit timeout remains the hard cap and progress does not extend it.

If an endpoint reboot interrupts a generated package download, OS image download, staged package extraction, or Windows desktop-readiness wait, Ordyn waits for the reconnected agent to synchronize replay protection and retries that preparation step. Recovery is limited to three attempts within 30 minutes. Other interrupted instructions 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 still terminal. 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.

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.

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 later execution should depend on a real runtime outcome rather than just continue_on_error.

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

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. Creating a job from a template materializes a normal job definition, so the resulting job can still be assigned, scheduled, triggered, audited, and used in orchestrations.

Template parameters 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 parameter model, synchronization behavior, and examples.

Job runs and history

Every execution of a job becomes a job run with per-endpoint targets and per-task execution records.

Operators can inspect:

• overall run status
• endpoint-level progress
• task output and errors
• 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.

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.

Jobs vs orchestrations

Use a plain job when one workflow should run against one resolved endpoint set.

Use a job orchestration when several jobs must run in controlled stages with:

• explicit rollout order
• per-stage scope selection
• batch size
• failure policy
• optional readiness checks

Jobs are the workflow logic. Orchestrations are the rollout logic above that workflow.

Related docs

Use this page as the feature overview.

For lower-level behavior and detailed reference, see:

• Automations
• Job Templates
• Orchestrations
• Variables
• Software Packages