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

Ordyn shows both on the scope pages for tenants, folders, groups, and endpoints.

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.

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.

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

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

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

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

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

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