Automations
Overview
The Automations page lets you define rules that fire when events happen across your fleet. Each rule combines a trigger (what starts it), one or more actions (what it does), and a target scope (which agents it affects). Rules are scoped to the current organization and require an org admin role to create or edit.
Navigate to Automations in the top nav bar (visible when signed in). The page has three tabs: Rules, Org Scripts, and Run History.
Stats Overview
Four stat cards at the top of the page provide a real-time summary:
| Card | Description |
|---|---|
| Active Rules | Number of enabled automation rules |
| Runs (24h) | Total automation executions in the last 24 hours |
| Success Rate | Percentage of successful runs in the last 24 hours |
| Org Scripts | Total scripts in the organization script repository (including system scripts) |
Tab 1: Rules
Lists all automation rules for the organization. Each rule card shows the rule name, enabled/disabled status, trigger → action summary, and last run time. Actions: Edit, Delete, and Run Now (for manual trigger rules).
Creating a Rule
Click + New Rule to open the rule editor modal.
| Field | Description |
|---|---|
| Rule Name | Descriptive name (e.g. "Notify on critical alert", "Restart spooler on enrollment") |
| Trigger | What starts the rule. Options below. |
| Action(s) | What the rule does when triggered. A primary action plus any number of additional actions added with + Add action. Options below. |
| Target Scope | Triggering Agent, All Agents, or agents matching a specific Tag |
| Enabled | Toggle on/off without deleting the rule |
Triggers
| Trigger | Fires When | Extra Options |
|---|---|---|
| Alert Fired | An alert rule triggers | Minimum severity filter (Critical, Warning, Info) |
| Security Detection | An agent reports a behavioral-security detection (after Behavioral Allowlist filtering) | AND/OR condition chain on detection fields (see below) |
| New Agent Enrolled | A new agent registers with the org | — |
| Agent Went Offline | An agent stops reporting | — |
| Agent Came Online | An agent reconnects | — |
| Ticket Submitted | An end-user submits a support ticket from the ET Ducky desktop agent | AND/OR condition chain on ticket fields (see below) |
| Script Submitted for Approval | A script enters pending review (for example a vendor patch script drafted from the Software Catalog). Context carries the script name, origin, type, and who submitted it, so you can route it to a notify/ticket/webhook action (e.g. ping an approver channel). | None |
| Application Installed | A new app appears in an agent's inventory (fires once per new (app name, version) pair; see Org-Wide App Inventory below) | AND/OR condition chain on app fields (e.g. Application Name, Publisher, Is Approved) |
| App Removed from Inventory | An application ages out of the org-wide app inventory — i.e. it has not been seen on any agent in the org for 7 days (see Org-Wide App Inventory below). The mirror of an install-time trigger, but for removal. | AND/OR condition chain on app fields: Application Name, Publisher, Platform, Was Approved |
| App Behavior Deviation | An application's observed behavior deviates from the per-application baseline built from your own fleet | — |
| Approved App Hash Mismatch | An approved application's primary binary hash diverges from the organization's reference hash in the binary-hash ledger (fires once per distinct divergent hash) | — |
| Catalog App Update Detected | A new version is detected for a Software Catalog entry | — |
| Time Entry Captured | Auto-capture creates a draft time entry when a live session, remote desktop session, shell session, or file transfer finishes (time_entry_captured) | AND/OR condition chain on entry fields: time_entry_id, source, clerk_user_id, agent_id, duration_seconds, ticket_id, description |
| Timesheet Submitted | A member submits a weekly timesheet for approval (timesheet_submitted) | AND/OR condition chain on: clerk_user_id, week, entry_count, total_seconds |
| Scheduled | On a recurring UTC cron schedule | Cron expression (5-field, e.g. 0 */6 * * *) |
| Manual | Only when you click Run Now | — |
Security Detection fires once per behavioral-security detection reported by an agent heartbeat (detections matching the Behavioral Allowlist are dropped first, so they never fire automations). Like Ticket Submitted, it offers an AND/OR condition chain so you can scope the rule — available fields: Severity (critical, warning, info, high, medium, low), Rule ID, Rule Name, Process Name, Title, and Agent ID. Pair it with an action such as Run Script (e.g. collect a forensic snapshot), Create Ticket, or Trigger Alert.
Ticket Submitted — Condition Builder
When the trigger is Ticket Submitted, the rule editor shows a condition chain that filters which tickets actually fire the rule. Add conditions with the + Add Condition button. Each condition has:
- AND / OR — How this condition connects to the previous result (the first condition seeds the result and ignores this field)
- Field — Device Name, Device ID, Ticket Title, Description, Keywords (searches both title and description), or Submitted By
- Operator — equals, does not equal, contains, does not contain, contains any of, starts with
- Value — The string to match. For contains any of, enter comma-separated values (e.g.
storage, low, error)
Example: fire only when a ticket comes from a device named "etducky" AND the title or description contains "storage", "low", or "error":
Condition 1: Device Name equals "etducky" AND Condition 2: Keywords contains any of "storage, low, error"
Actions
| Action | What It Does | Configuration |
|---|---|---|
| Run Org Script | Executes a script from the org repository on target agent(s) via SSE | Script picker (from Org Scripts tab), shell type (PowerShell/CMD) |
| Fire Webhook | Sends an HTTP request to an external URL | URL, method (POST/PUT/GET), custom headers (JSON), body template with {{variables}} |
| Trigger Alert | Dispatches a notification through an alert channel (email, webhook, Slack, Teams, PagerDuty) | Alert Channel picker, custom message template |
| Create Ticket | Creates a native ET Ducky ticket | Ticket summary template with {{variables}} |
| Remove from Approved Apps | Removes the triggering app (or a configured app) from the organization's Approved Applications list. A no-op if the app is not on the list. Built to pair with the App Removed from Inventory trigger, which supplies the app name. | None (uses {{app_name}} from the trigger context) |
| Classify Time Entry | Sets the billing status (billable, non-billable, or logging only) and optionally the category on the captured time entry. Only applies while the entry is still a draft. Built to pair with the Time Entry Captured trigger and its conditions (e.g. source = remote_desktop AND agent tagged client-x becomes billable). | Billing status, optional category |
| Push Time Entry to PSA | Forwards the captured time entry to the organization's PSA webhook as a time_entry.captured event. | None (uses the webhook configured under Integrations → PSA) |
| Create Invoice Draft (Stripe) | Creates one draft Stripe invoice from approved billable time for the previous week (Monday-Sunday, default) or the previous calendar month, computed at run time. Commonly paired with a Scheduled trigger for monthly billing. Requires the Stripe billing connector. | Billing period: previous week (default) or previous calendar month |
Multiple actions per rule
A rule is not limited to a single action. The rule editor has a multi-action composer: the action you configure first is Action 1, and the + Add action button appends ordered steps (Action 2, Action 3, …), each with its own action type and configuration. When the rule fires, the engine runs the steps in order, top to bottom — and stops at the first step that fails (after that step exhausts its retries), so a later step never runs if an earlier one it depends on failed. Each step records its own entry in Run History (labelled step N/total). A rule with no added steps behaves exactly as a plain single-action rule.
Template Variables
Webhook body templates, notification messages, and ticket summaries support these placeholders:
{{ruleName}}— The automation rule name{{triggerType}}— The trigger that fired (e.g. alert_fired, agent_enrolled){{agentName}}/{{agentId}}— The triggering agent's name or ID{{alertName}}— The alert rule name (when trigger is alert_fired)
Org-Wide App Inventory
ET Ducky maintains an org-wide inventory of applications present across every agent in the organization — both approved and unapproved. Each app entry tracks when it was last seen on any agent. When an application is absent from every agent for 7 days, it ages out of the inventory. That age-out is what fires the App Removed from Inventory trigger, with the app's name, publisher, platform, and whether it was on the Approved Applications list carried as context.
This complements the install-side view: the Application Installed trigger fires the moment a new app appears in an agent's inventory, while App Removed from Inventory fires once an app has fully disappeared from the fleet. A natural pairing is to chain App Removed from Inventory → Remove from Approved Apps, so the approved list auto-prunes applications nobody runs anymore.
Tab 2: Org Scripts
View and manage the organization's shared script repository. This is the same script library used by Live Session's Shell tab (the "Select Script" dropdown) and Fleet Tools. Scripts created here appear everywhere, and vice versa.
Script Properties
| Field | Description |
|---|---|
| Name | Unique name within the org (e.g. restart-spooler.ps1) |
| Type | PowerShell or CMD |
| Category | Diagnostics, Maintenance, Security, Inventory, Compliance, Imported, or Custom |
| Description | Brief summary of what the script does |
| Content | The script body (supports parameters and {{placeholder}} substitution) |
System scripts are read-only and shared across all organizations. They provide common diagnostics (Get CPU and Memory Usage, Get Disk Space, Get Event Log Errors, etc.), inventory (Get Installed Software, Get Hardware Info), and maintenance tasks (Clear DNS Cache, Flush Print Queue). Custom scripts can be created, edited, and deleted by org admins.
AI-Generated Remediation Scripts (Process Automations)
Beyond scripts you write or import yourself, the AI-driven diagnostic agent can propose remediation scripts at the conclusion of an investigation (see AI Diagnostics). When a guided troubleshooting session lands on a known-fix pattern, the AI generates a PowerShell or Bash script targeting the specific issue and submits it to your org's Process Automations repository for review — the same approval flow that protects scripts generated by the documentation recorder.
Script properties at submission
| Field | Value |
|---|---|
| Origin | process_automation |
| CreatedBy | dynamic-etw:<jobId> — ties the script back to the investigation that produced it |
| Approval status | pending_review — no execution until an org admin approves |
| Review ticket | A ticket is filed in the org's ticketing system referencing the script; org admins approve or reject there |
| Auto-run eligibility | Mode-dependent (see below) |
Auto-run eligibility by mode
- Live guided-troubleshooting session, operator attending →
auto_run_eligible = true. After org-admin approval, the operator can run the script immediately in the live session through the existing automations execution path (which itself enforces command security policy). - Background / scheduled / dashboard-initiated investigation, no operator →
auto_run_eligible = false. The script stays in the repository as analysis-only; a human picks it up, reviews, and decides whether to run. - Desktop interactive session → runs entirely on the desktop user's own machine; reviewed and run directly in the desktop's Dynamic Diagnostics page (no cloud approval gate for the user's own machine, but every execution is logged locally to
%LOCALAPPDATA%\ET_Ducky\dynamic-remediation-audit.jsonlfor audit).
The product invariant — ET Ducky does not take unauthorised actions on customer hosts — applies equally to AI-generated scripts and to scripts written by humans. The approval gate, per-command security policy, and org-admin role check are the same.
Tab 3: Run History
A chronological log of all automation executions across all rules. Each entry shows:
| Column | Description |
|---|---|
| Rule | The automation rule that ran |
| Trigger | What triggered the execution |
| Action | What action was performed |
| Target | Agent ID, agent count, or scope description |
| Status | Success (green) or Failed (red) with error details |
| When | Relative timestamp |
Failed runs include error messages to help diagnose issues (e.g. "Script not found", "Webhook returned 403", "No valid agents found").
Automation Scheduler
Cron-based rules are evaluated by a background service that runs every 60 seconds. When a scheduled rule's next run time has passed, the rule is executed and the next run time is recalculated from the cron expression. Common patterns:
| Cron Expression | Schedule |
|---|---|
*/15 * * * * | Every 15 minutes |
0 */6 * * * | Every 6 hours |
0 8 * * 1-5 | 8:00 AM UTC, weekdays only |
0 3 * * * | 3:00 AM UTC daily (maintenance window) |
All times are evaluated in UTC. If a scheduled run fails, the next run time still advances so the scheduler doesn't retry the same failed execution repeatedly.
Example Workflows
Auto-remediate high CPU
Create an alert rule for CPU > 95% for 300 seconds. Create an automation rule with trigger "Alert Fired" (min severity: Critical), action "Run Org Script" (select a script that restarts the offending service), target "Triggering Agent".
Onboarding script for new agents
Create a script that configures Windows Update settings, installs monitoring prerequisites, or sets local policy. Create an automation rule with trigger "New Agent Enrolled", action "Run Org Script", target "Triggering Agent".
Slack notification on agent offline
Create an automation rule with trigger "Agent Went Offline", action "Fire Webhook" pointed at your Slack incoming webhook URL, with a body template like {"text": "Agent {{agentName}} went offline"}.
Daily fleet health report ticket
Create an automation rule with trigger "Scheduled" (0 8 * * 1-5), action "Create Ticket" with summary "[Auto] Daily fleet health check - {{triggerType}}", target "All Agents". Review the ticket each morning for overnight issues.
Catch unapproved app installs
Pair the Application Installed trigger with the Approved Applications list to surface shadow-IT installs the moment they appear in inventory. Create an automation rule with:
- Trigger: Application Installed
- Trigger conditions: add one condition with Field=
is_approved, Operator=equals, Value=false - Action: Create Ticket with summary "[Unapproved] {{app_name}} v{{app_version}} installed on {{agent_name}}", or Fire Webhook to Slack/Teams with a body template like
{"text":"⚠ Unapproved install: {{app_name}} ({{publisher}}) on {{agent_name}}"} - Target: Triggering Agent
The trigger fires once per new (app name, version) pair detected when comparing the agent's latest inventory snapshot against the prior one. First-ever snapshots for an agent skip the diff so enrolling agents don't fire one rule per pre-existing installed application. Available context variables: {{app_name}}, {{app_version}}, {{publisher}}, {{source}}, {{is_approved}}, {{agent_id}}, {{agent_name}}, {{os}}.
Auto-prune approved apps nobody runs
Keep the Approved Applications list tidy by removing entries for software that has left the fleet entirely. Create an automation rule with:
- Trigger: App Removed from Inventory (fires when an app has been absent from every agent for 7 days)
- Trigger conditions (optional): add Field=
was_approved, Operator=equals, Value=trueto act only on apps that were on the approved list - Action: Remove from Approved Apps — it uses
{{app_name}}from the trigger context to drop the matching approved-list entry (no-op if it isn't there)
Because rules support multiple actions, you can add a second step — for example a Trigger Alert or Create Ticket step — so an admin is notified whenever an app is auto-pruned.