Automation rules and controls
Submission and ticket rules support LIVE and OBSERVE modes, campus conditions and draft previews. OBSERVE records WOULD_HAVE_RUN in the run ledger and applies no action or notification. A matched stop-processing rule still stops the remaining rules in either mode. Preview evaluates up to 500 recent eligible records and shows up to 20 matches without saving a rule or running its actions. Updated, breached and stalled previews evaluate current record state, not a reconstruction of historical changes.
Admin → Automation exposes school-wide hourly limits (workflow.manage): 60 admitted matches per rule and 500 across the tenant by default, with zero disabling that limit. Observe matches consume the same allowance. Admission serialises the count and reservation in a tenant-specific database transaction. Configuration/count failures refuse the action. REFUSED ledger rows explain cap failures and do not consume allowance.
Unattended device.lock requires a compatible connector implementing that capability and serial lookup. No bundled connector currently declares device.lock; the approval mechanism fails closed until one does. It must not be described as working fleet locking merely because the core capability name exists. Other device commands remain on their existing interactive paths.
A supported lock freezes its ticket, connector instance, serial and connector-resolved device ID before being offered in Admin → Automation. device.manage can approve or decline. Only one decision can win, and its audit record commits with the transition. Approval queues the frozen action; changing the ticket’s device invalidates execution. Configuration-supplied device IDs cannot redirect it.
Dispatch claims are atomic across API processes. Lock errors are terminal and marked unconfirmed because a timeout cannot prove the provider rejected the action. An accepted action whose success record fails to save is never automatically resent. Dispatches left in progress for over 15 minutes become FAILED with an instruction to verify the external outcome. Other failed outbound actions retain their three-attempt retry behaviour. Both the Tickets and Automation modules must be enabled for queued dispatch.
Rule changes are audited in the same transaction as the change, including every edited field. Reading rule-wide run history requires workflow.manage.