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), an action (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 | What the rule does when triggered. 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) |
| 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) |
| Scheduled | On a recurring UTC cron schedule | Cron expression (5-field, e.g. 0 */6 * * *) |
| Manual | Only when you click Run Now | — |
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}} |
| Send Notification | Notifies org admins or fans out via alert webhook channels | Channel (email or webhook), custom message template |
| Create Ticket | Creates a native ET Ducky ticket | Ticket summary template with {{variables}} |
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)
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}}.