Automations

Jobs can run automatically in two ways:

• time automations run a job on a schedule or once at a specific time
• event automations run a job when something happens on an endpoint or inside another job

Endpoint job automations are configured on tenant, folder, group, and endpoint scope pages. An endpoint job's assignment automation is configured on that job's Automations tab. Infrastructure job automations are configured on the infrastructure job's Automations tab.

Configuration profile automations are configured inside each profile assignment. They use their assignment's behavior and desired settings and remain separate from the job automations described on this page. See Configuration Profiles.

Endpoint Time Automations

Time automations run jobs by clock time.

Use them when you want a job to start:

• on a recurring schedule
• once at a specific time
• later, when a disconnected endpoint reconnects

The automation table shows the automation name, job, schedule details, and the next run.

What you configure

For a time automation you typically set:

• the job to run
• the target scope
• a cron expression or one-time run timestamp
• the timezone
• whether missed runs should execute on the next connect

How they behave

Time-based automations are evaluated per endpoint.

That means:

• connected endpoints run immediately when the automation is due
• disconnected endpoints are skipped unless Run on next connect if missed is enabled
• if that option is enabled, Ordyn keeps one deferred execution for the endpoint and runs it after the endpoint reconnects
• repeated missed schedule times do not create multiple deferred runs

If a time automation is disabled or edited, any deferred execution waiting for reconnect is cleared.

Ordyn also respects job validity windows and endpoint job disables when a schedule is due.

Endpoint Event Automations

Event automations run a job when an endpoint or another job reaches a specific event.

Current event types are:

• alert_activated
• endpoint_connected
• job_assigned
• post_enrollment
• system_boot
• system_shutdown_requested
• user_logon
• user_logoff
• snmp_trap_received
• webhook_received
• job_completed

They mean:

• alert_activated runs when one selected alert rule enters the triggered state for an endpoint
• endpoint_connected runs when an approved endpoint opens a real relay connection
• job_assigned runs the selected endpoint job when an endpoint gains its first effective assignment to that job
• post_enrollment runs after a newly approved endpoint reports its first system status
• system_boot runs after an endpoint reports a different operating-system boot identity
• system_shutdown_requested runs when an endpoint starts a normal system shutdown
• user_logon runs when a user starts an interactive Windows console or Remote Desktop session
• user_logoff runs when a user ends an interactive Windows console or Remote Desktop session
• snmp_trap_received runs when a matching SNMP trap is accepted
• webhook_received runs when an assigned webhook receives and accepts an external HTTP request for the endpoint
• job_completed runs when a specific base job reaches one of the selected terminal states

Scope

Event automations can be attached to:

• a tenant
• a folder
• a group
• a single endpoint

The same scope resolution rules used elsewhere in Ordyn apply here: event automations inherit through the chosen scope and can also be created directly on a specific endpoint.

job_assigned is configured differently. Open the endpoint job itself and select its Automations tab. The rule covers direct, group, folder, and tenant assignments for that job, so it does not need a separate target scope.

What you configure

For an event automation you typically set:

• the trigger job
• the scope
• the event type
• the order among other automations of the same event type
• an optional jitter window

For job_completed, you also choose:

• the base job that must finish first
• the terminal statuses that count as a match

For alert_activated, you also choose the alert rule. It runs once when the rule becomes triggered, not on repeated triggered evaluations, acknowledgement, errors, or resolution.

For webhook_received, you also choose:

• the webhook definition that must receive the request

For snmp_trap_received, you choose:

• the exact trap OID
• Endpoint Primary Interface or Any Source
• a cooldown from 0 to 86400 seconds

Endpoint Primary Interface matches the trap source IP against the primary host interface of approved SNMP endpoints in the automation scope. It does not compare endpoint hostnames or secondary interfaces. Multiple endpoints with the same primary IP all match.

Any Source ignores the sender address and fans the automation out to every approved SNMP endpoint in the scope that is assigned to the SNMP service client which received the trap. Folder scope includes descendant folders. Group, tenant, and endpoint scopes work as usual. Because a single trap can start jobs on many endpoints, administrators are responsible for choosing an appropriately narrow scope and OID.

The cooldown applies once to the whole automation rule and its fan-out. After a fan-out starts, another matching trap during the cooldown does not start the selected job for any target from that rule. Random delay and normal job eligibility or active-run coalescing continue to apply separately to each target.

For job_assigned, select Run when assigned on the endpoint job's Automations tab. Each endpoint job can have one assignment automation.

User logon and logoff automations do not have user or session filters. They run only for confirmed local console and Remote Desktop sessions, not for lock, unlock, Remote Desktop disconnect, reconnect, or unclassified session events. Events identified as Ordyn's managed desktop automation account are accepted but do not run jobs or configuration-profile checks.

System boot automations start from system status reported after the agent is running. The endpoint must be online long enough to report its new system status and receive the triggered work; offline boots are not replayed as separate events.

Endpoint History recording for user logon and logoff is controlled separately by audit.record_user_session_events in Administration Settings and is disabled by default. System boots are always recorded. Turning user-session recording off does not disable job or profile triggers.

How they behave

Ordyn runs matching event automations in their configured order.

When a trigger is ready to fire, Ordyn adds a random delay up to the configured jitter before dispatching it. This helps avoid bursts when many endpoints match at once.

If the same job is already pending or running for the endpoint, a system-boot or user-session trigger is coalesced instead of starting another copy. The Windows agent may briefly delay a logon event while Windows makes its session details available and keeps an unacknowledged event for up to 15 minutes while reconnecting. A confirmed console or Remote Desktop event can still trigger when Windows does not provide the account name; in that case the session principal is empty. Events without a principal are treated as normal user-session events.

Requester handling depends on the event:

• endpoint_connected uses the user who created the automation
• webhook_received uses the user who created the trigger rule
• job_completed inherits the requester from the source job run

For job_completed, Ordyn only dispatches when the base job finishes with one of the selected terminal statuses.

For webhook_received, Ordyn only dispatches when the received webhook belongs to the same endpoint as the trigger rule. Triggered jobs receive the normalized request under trigger.webhook and configured mapped values under webhook.*.

For snmp_trap_received, the trap must be accepted by the SNMP service client assigned to the target endpoint. Triggered jobs receive the same normalized trap under trigger.snmp for every endpoint selected by the rule.

Triggered jobs also receive the common trigger.* fields for the run origin. See Variables for the full list.

Assignment automation behavior

An assignment automation reacts to the endpoint's effective assignment, not to each individual assignment record.

This means:

• the first direct, group, folder, or tenant assignment starts the job
• adding another overlapping assignment does not start it again
• removing one assignment while another remains effective does not start it again
• after all effective assignments are removed, a later assignment can start it again
• assignments that already exist when you enable the automation are treated as the starting state and do not start the job retroactively

Normal job eligibility rules still apply when the assignment is detected. For example, a disabled job, an invalid validity window, or an already active copy can prevent a new run; Ordyn does not save that assignment event for a later retry.

Dynamic group changes use the endpoint's currently evaluated membership. If a job changes a persistent variable that should move its endpoint into or out of a dynamic group immediately, add the Refresh dynamic group memberships step after the variable change. The step re-evaluates all dynamic groups available to the current endpoint before the next step continues. This explicit refresh can be more expensive in tenants with many dynamic groups, so add it only where the workflow needs immediate membership changes.

Infrastructure Job Automations

Infrastructure automations start a job once without resolving endpoint targets. Open Operations > Infrastructure Jobs, select a job, and open its Automations tab.

The tab contains:

• time automations for recurring or one-time schedules
• Job completed event automations
• Webhook received event automations
• Windows update approved event automations

Infrastructure Time Automations

Configure:

• a name
• a cron expression or one-time run timestamp
• the timezone
• Enable

Each due time creates one run of the infrastructure job. The run uses the Runner pool selected in the job overview. There is no endpoint scope or next-connect option.

Infrastructure Completion Automations

A Job completed automation treats the current infrastructure job as the source event and starts a selected infrastructure job after the source reaches one of the selected outcomes:

• succeeded
• failed
• timed out
• aborted

Configure an optional maximum random delay from 0 to 3600 seconds to spread follow-up work. The source job cannot select itself as the follow-up job.

Infrastructure Webhook Automations

A Webhook received automation starts the current infrastructure job when the selected infrastructure-scoped webhook accepts a request.

The job receives the normalized request under trigger.webhook and configured mapped values under webhook.*. The request does not choose the job, Runner pool, Runner, or endpoint.

The optional maximum random delay can be set from 0 to 3600 seconds.

See Webhooks for webhook setup, authentication, and variable mappings.

Infrastructure Windows Update Approval Automations

A Windows update approved automation starts the current infrastructure job when updates enter the approved state in any enabled Windows update ring. Manual approvals, automatic approvals, and enabling a ring that already contains approvals can trigger it.

Configure a debounce from 0 to 3600 seconds. The default is 60 seconds. Approvals during the delay are combined and reset the delay. If a run from the same automation is already active, Ordyn keeps one combined follow-up instead of starting an overlapping run.

The run context contains the approval count, ring IDs, approval sources, reasons, and first and last event times. Individual update IDs are not included. Clearing or rejecting an approval during the debounce does not cancel the pending run.

Infrastructure job validity windows apply to scheduled, completion-triggered, webhook-triggered, and Windows-update-approval starts.

Where To Manage Them

Use the scope pages when you want to create, edit, copy, delete, or reorder automations.

The endpoint Jobs tab shows the scope-based automation model from the endpoint side, split into:

• time automations
• event automations

That view is useful when you want to see why a job will run on a specific endpoint.

For an assignment automation, use the endpoint job's Automations tab. For infrastructure jobs, use the infrastructure job's Automations tab to create, edit, or delete its time and event automations.

Common patterns

Use a time automation when:

• you want a recurring maintenance job
• you want a one-time rollout at a fixed time
• you want missed runs to wait until the endpoint reconnects

Use an event automation when:

• you want a job to run after enrollment completes
• you want a follow-up job after another job finishes
• you want to react to endpoint connect or shutdown events
• you want initialization work to run after an endpoint reports a new operating-system boot
• you want to react when a Windows user logs on or logs off
• you want an external system to trigger an endpoint job through a webhook
• you want an endpoint job to run when it first becomes assigned
• you want one infrastructure job to start after another infrastructure job completes
• you want an external system to trigger an infrastructure job through a webhook

See Infrastructure Jobs for the complete infrastructure workflow.