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). Run Now runs only enabled rules. For a disabled rule it answers “This automation is disabled. Run Now runs only enabled automations. Enable it in the rule editor, then run it again.”

Creating a Rule

Click + New Rule to open the rule editor modal.

Field	Description
Describe it	Optional, for organization admins and owners. Describe the rule in your own words and press Draft with AI to fill in the form. See Describe an Automation.
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. Not fired yet: a rule with this trigger can be saved but does not run.	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. Not fired yet: a rule with this trigger can be saved but does not run.	—
Agent Came Online	An agent reconnects. Not fired yet: a rule with this trigger can be saved but does not run.	—
Ticket Submitted	A native ET Ducky ticket is opened: an end-user submits one from the ET Ducky desktop agent, a technician creates one on the dashboard, a visitor reports a problem on the status page, or a scheduled automation misses a run	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 cron schedule, in UTC (see Automation Scheduler)	Cron expression (5-field, e.g. `0 3 * * 1-5`)
Data Condition (Smart Reports)	A Smart Reports data source has rows that match your filters, checked every few minutes (see Data Condition trigger)	Data source, filters, how the rule runs, threshold, look-back and check interval
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

Webhook secrets: Webhook URLs, custom headers and body templates can hold credentials, so only organization admins and owners see them in the rule editor. No member privilege grants access to them. Other members see the URL's host followed by a placeholder such as [hidden-0], each header name with a placeholder value, and a placeholder body template. The number names the action the value belongs to (Action 2's values show 2, Action 3's show 3, and Action 1's show 0), so a hidden value stays with its action when other actions are removed. Saving a rule with a placeholder left as it is keeps the stored value, and typing a new value replaces it. Changing the URL clears hidden headers and a hidden body template, so they are never sent to a new address. Run History records only the scheme and host of the URL a webhook action called. Run History entries recorded before this change were rewritten the same way.

Native vs. external tickets: The Create Ticket action always creates a native ET Ducky ticket. To automatically open an incident in an external system (ServiceNow or Jira), use the Fire Webhook action pointed at the provider's API — see Auto-open a ServiceNow or Jira incident below. The built-in Jira/ServiceNow integration handles host→ticket lookups and troubleshooting-summary push, not automation-driven creation.

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)

Organization admins and owners can export every automation rule to a file and import rules from one. Imported rules start disabled, and webhook URLs, headers and body templates are not included in the file. See Configuration Export and Import. To bring rules over from another RMM tool, follow Moving a setup from another tool, step by step.

Describe an Automation

The rule editor has a Describe it box above Rule Name. Type what you want in your own words, for example “when an unapproved application is installed, create a ticket assigned to sam and run the Clear Temp script”, and press Draft with AI. The draft is made on the server while the box shows its progress, and ET Ducky then fills in the form below with it. Nothing is saved: review the form, change what you need, tick Enabled when the rule is ready (a draft leaves it unticked), and press Save Rule. The rule is saved and checked the same way as a rule you fill in by hand.

Who can use it: organization admins and owners, for the organization they are signed in to, on any paid plan, including plans with agent seats only. Other members get the answer “Only organization admins and owners can draft automation rules with AI.” An organization without a paid plan gets “AI drafts are part of every paid ET Ducky plan, including plans with agent seats only.”
What a draft can use: the triggers, condition fields, actions and target scopes on this page, any 5-field cron schedule (in UTC), and your organization's approved scripts, system scripts, agent tags, enabled alert channels and members. A draft never writes script code and never adds the Approve Linked Automation action.
Names: scripts, tags, alert channels and people are matched by name to the items in your organization. A name that matches nothing, or more than one item, is listed under Could not match and its field is left empty for you to choose. People are matched by the part of their sign-in address before the @.
Notes: the box lists the assumptions the draft made and every value it left empty, for example a condition the editor cannot express for the trigger, or a Target Scope, which limits only Run Script steps.
Webhooks: a webhook URL or header is filled in only when you typed it in the description. Credential-like text in names, messages and ticket summaries is replaced with [removed].
Requests ET Ducky cannot run, such as a schedule cron can't express or a trigger nothing fires, give no draft and a note saying why. The form is not changed. A draft never uses the Data Condition trigger; choose it in the form yourself.
Limits and cost: 2,000 characters per description. There is no limit on how many drafts an organization makes. Each draft uses your organization's AI queries, metered by tokens, unless your organization's own BYOK key makes it (see AI Usage). When the queries are used up and the organization has no key of its own that works, the box says how to get more queries or add a key. When your own key fails a draft and ET Ducky's provider makes it instead, the notes say the draft was charged to your organization's AI queries.
Waiting: when the AI provider does not answer in time or limits requests, the draft is tried again up to three more times, after 20, 60 and 120 seconds, and the box shows the wait. When the box gets no answer from ET Ducky while it checks on the draft, it says it is waiting and checks again. When your own key does not answer in time and the organization has no AI queries left for ET Ducky's provider to take over, the draft fails at once instead of waiting. If the ET Ducky server making the draft stops first, the draft fails too. Each ET Ducky server makes at most two of one organization's drafts at once; others wait their turn, with no limit on how many wait.
Retry: when a draft fails, a Retry button appears beside Draft with AI. It starts a new draft from the same description, which only this page holds. If you changed the description since, press Draft with AI instead.
Records: the description, the names of your organization's scripts, tags and alert channels, and the part of each member's sign-in address before the @ (the whole address when two members share that part) go to your organization's AI provider, or ET Ducky's, to make the draft. ET Ducky does not store the description: the server that receives it keeps it in memory only until the draft is finished. The finished draft is kept for an hour so the editor can read it, then deleted. The audit log records each draft with its trigger, action types and counts, never the description or the drafted text.

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.

System scripts are the Default Scripts repository under Integrations → Script Repositories. They are platform-provided and read-only, and they run as published. A system script runs by id from Fleet Tools, from the Live Session Shell tab and from a Run Org Script automation step. It passes the command screens as a system script only when the text sent is exactly its stored text; any other text sent with its id is screened as the text it is.

Microsoft Defender Changes in Scripts

A command or organization script may harden Microsoft Defender. Every other Defender change is refused before it reaches an agent, whatever script id is sent with it. No reviewer approval overrides the refusal. Make those changes through endpoint management policy instead: Intune, Group Policy or the Defender portal.

Allowed

Set-MpPreference with -Disable* parameters set to $false; signature update interval and schedule; scan and remediation schedules; scan parameters; cloud extended timeout; -EnableControlledFolderAccess, -EnableNetworkProtection and -PUAProtection set to Enabled; -MAPSReporting Basic or Advanced; -SubmitSamplesConsent AlwaysPrompt, SendSafeSamples or SendAllSamples; -CloudBlockLevel High, HighPlus or ZeroTolerance.
Add-MpPreference adding attack surface reduction rules with the action Enabled, or adding controlled folder access protected folders.
Remove-MpPreference removing exclusions (path, extension, process, IP address), controlled folder access allowed applications, or attack surface reduction exclusions.

Each parameter must be written out in full with a literal value. Unknown parameters, abbreviations and aliases, variables, splatting, subexpressions and positional arguments are refused.

Refused

Adding exclusions, setting a -Disable* parameter to $true, setting attack surface reduction rules to audit or off, and adding allowed applications.
Registry writes to Defender policy, settings or service keys.
Stopping, reconfiguring or killing a Defender service or process.
Writes to Defender preferences through WMI or CIM.
Removing Defender definitions (MpCmdRun -RemoveDefinitions) or the Defender feature.

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 an Automated 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. This is 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 Automated 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.jsonl for 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

Scheduled rules are evaluated by a background service that runs every 60 seconds. When a scheduled rule's next run time has passed, the rule runs in its own organization and the next run time is set from the schedule. Schedules run in UTC: ET Ducky does not store a time zone for an organization or workspace, so convert local times to UTC when you write the expression.

The cron expression has five fields separated by spaces:

Field	Values
Minute	0 to 59
Hour	0 to 23
Day of month	1 to 31
Month	1 to 12, or JAN to DEC
Day of week	0 to 7 (0 and 7 are Sunday), or SUN to SAT

Each field takes * (every value), a number, a list (1,15), a range (1-5) or a step (*/15, 9-17/2, or 5/20 for 5, 25 and 45). Names are not case-sensitive. When both day fields are restricted, a day matches if either one matches; a field that starts with * counts as unrestricted. Seconds, @daily-style shortcuts and L, W, # or ? are not accepted.

Cron Expression	Runs
`/15 * * *`	Every 15 minutes, at :00, :15, :30 and :45
`0 /6 * *`	At 00:00, 06:00, 12:00 and 18:00 UTC
`0 3 * * *`	At 03:00 UTC every day
`0 8 * * 1-5`	At 08:00 UTC, Monday to Friday
`30 2 1 * *`	At 02:30 UTC on the first day of each month
`0 0 31 * *`	At midnight UTC on the 31st, in the seven months that have one

The rule editor refuses an expression it can't run, with a sentence saying which field is wrong, and refuses one that never runs (for example the 30th of February). An import or AI draft is checked the same way. If ET Ducky was unavailable at a scheduled time, the rule runs once when the scheduler next looks, provided that is within an hour; a run missed by more than an hour is skipped and the rule waits for its next time. A skipped run opens a ticket in the organization, titled “Scheduled automation missed a run” with the rule's name, saying when the run was missed and when the next one is; while that ticket is open (not Resolved or Closed, and not archived), each later miss of the same rule adds a note to it instead of opening another, so a rule never has more than one open missed-run ticket. Like any new ticket, a missed-run ticket starts rules with the Ticket Submitted trigger once, when it is opened; notes added for later misses start nothing. A rule saved before these checks whose expression ET Ducky can't read does not run, and the server log records it once; open the rule and save a valid schedule. A rule saved before these checks with a valid expression runs at its first scheduled time after the update, not at once. If a scheduled run fails, the next run time still advances so the scheduler doesn't retry the same failed execution repeatedly.

Data Condition Trigger

The Data Condition (Smart Reports) trigger runs a rule when one of the data sources Smart Reports and Data Explorer use has rows that match your filters. ET Ducky checks each enabled rule every few minutes in the rule's own organization, with the same query rules as Data Explorer: the allowlisted sources and columns, parameterized filters and your organization only.

Data source: any source every member of the organization can read in Data Explorer, such as agents, health metrics, events, tickets, alert history or installed applications. Sources that need a privilege, such as time entries, are not offered, because a rule runs with no one signed in and can send what it finds to webhooks, tickets and alert channels.
Filters: up to 10, all of which must match: equals, does not equal, contains, greater than, at least, less than, at most, is one of, is none of, is empty and is not empty.
Once for each new matching value: choose the column that identifies a match, for example Agent ID or Server Name, and how many matching rows a value needs (default 1). The rule runs once for each value that starts matching, and again only after that value has stopped matching for one check. When the column is Agent ID and the value is an active agent of the organization, that agent is the triggering agent, so a Run Script step with the Triggering Agent scope runs on it.
When the number of matching rows crosses a threshold: the rule runs when the count reaches the threshold (at least), or drops under it (below), and runs again only after the count has gone back the other way. Below with a threshold of 1 runs when nothing matches, for example when no health data arrived in the last hour. It has no triggering agent.
Look-back: for sources with a time column, only rows from the last 5 to 10,080 minutes count (default 60). Sources without a time column, such as agents, are read as they are now.
Check every: 5 to 1,440 minutes (default 15). The first check comes within a minute of enabling the rule.
Templates: the webhook body, the Trigger Alert message and the ticket summary can use {{data_source}}, {{count}}, {{threshold}} and, for a matching value, the column's name (for example {{AgentId}} or {{ServerName}}). A ticket summary longer than 500 characters is cut. The trigger conditions chain used by other triggers does not apply; put conditions in the filters.
Limits: by default, one check reads at most 2,000 values (or 10,000 rows when counting a source without a time column) and runs the rule at most 25 times; the rest run at the next check. A check whose query takes longer than 20 seconds is stopped, and a check whose query times out or fails is tried again after an hour (or the rule's own interval, if longer); the status line says which. There is no limit on how many Data Condition rules an organization can have. ET Ducky looks for due rules once a minute and takes at most 10 from one organization each time (by default), so when many of an organization's rules are due at once, some are checked a minute or two later.
Who can use it: organization admins, owners and technicians (members holding the workspace technician privilege), on any paid plan, including plans with agent seats only. Other members get “Only organization admins, owners and technicians can save a rule with the Data condition trigger”. An organization without a paid plan can't save such a rule enabled (it can still save one disabled, for example to switch it off), and its existing ones are not checked until it has one.
Status: the rule editor shows when the rule was last checked, how many rows or values matched, when it last ran and, when a check did not run, why. ET Ducky keeps only a hash of each matching value, not the value.

Example Workflows

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

Daily fleet health report ticket

Create an automation rule with trigger "Scheduled" (0 6 * * *, at 06:00 UTC every day), action "Create Ticket" with summary "[Auto] Daily fleet health check - {{triggerType}}", target "All Agents". Review the ticket each day for issues since the last one.

The Alert Fired, Agent Went Offline and Agent Came Online triggers do not start rules yet. To act on agents that stop reporting, use the Data Condition example below. To be told when an alert rule fires, link a notification channel to the alert rule (see Alerts).

Ticket for each agent that stopped reporting

Create an automation rule with trigger "Data Condition (Smart Reports)", data source Agents, filter Is Online equals false, run once for each new matching value of Agent ID, check every 15 minutes, and action "Create Ticket" with summary "Agent {{AgentId}} is offline". Each agent gets one ticket when it goes offline, and another only after it has come back and gone offline again.

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=true to 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.

Auto-open a ServiceNow or Jira incident on a behavioral detection

The Create Ticket action files a native ET Ducky ticket; to raise an incident directly in ServiceNow or Jira, use Fire Webhook against the provider's REST API. Create an automation rule with:

Trigger: Security Detection — optionally add a condition chain (e.g. Severity contains any of critical, high) to scope which detections fire it
Target: Agents matching a specific tag — choose the tag whose machines this rule should cover
Action: Fire Webhook. ServiceNow: method POST, URL https://<instance>.service-now.com/api/now/table/incident, headers {"Content-Type":"application/json","Authorization":"Basic <base64 user:pass>"}, body template {"short_description":"ET Ducky automation {{ruleName}} fired on {{agentName}}","urgency":"2"}
Jira: POST to https://<domain>.atlassian.net/rest/api/3/issue with the issue JSON in the body and an Atlassian API token in the Authorization header

Use the native Create Ticket action instead when you don't need the incident to appear in the external system. The automation posts to the provider API directly — the Jira/ServiceNow integration under Integrations is used for host→ticket lookups and pushing troubleshooting summaries, not for automation-driven incident creation.