Create and govern automation rules
Define what happens when a detection fires or on a schedule, constrain its device scope, and verify its observed results.
Before you start
- Enable the detection or choose a schedule before building the rule.
- Create an eligible script before adding a run-script step; configure ITSM before adding a ticket step.
Screenshots show the Rapport interface with example data. Use your organization’s devices and values. Select an image to view it at full size.
Inspect existing rules before creating another
Open Rules. Search by rule, detection, or script, and filter by trigger, state, origin, or detection. Read its natural-language summary, observed success, recent fires, approval state, and last activity.
What you should see: You know whether to inspect, clone, or create a rule.
Choose a detection or schedule trigger
Choose New rule. Select When a detection fires or Scheduled. Detection rules require an enabled current detection. Scheduled rules use a five-field schedule and a named time zone.
| Field or control | What to do |
|---|---|
| Detection trigger | Runs only when the selected enabled detection produces a condition. |
| Scheduled trigger | Runs at the displayed local schedule and stores a separate time zone. |
Limit the device scope
Choose platforms, tags, organizational units, and/or explicit devices. Read the matched-device count. An empty dimension means no restriction for that dimension; it is not an empty fleet.
What you should see: The preview describes the intended device population.
Add reviewable steps
Add an eligible machine-context script for each supported platform, or add a ticket step to a detection rule when ITSM is enabled. Confirm parameters and platform compatibility. A scheduled rule may run scripts but cannot use a ticket-only step.
Set guardrails, verification, and notification
Configure cooldown, hourly cap, maintenance window, priority, and—where supported—verification time and success floor. Choose a notification target and the moments that should be delivered. New rules start in Shadow so observed behavior can be reviewed before activation.
Review the sentence and save
Read the generated When / Where / Then / Guardrails / Notify summary. Save only when it names the correct detection or schedule, devices, steps, and limits. Reload on a revision conflict instead of overwriting another administrator’s changes.
What you should see: The saved rule has a stable revision and a complete, reviewable scope.
Use Activity to verify results
Open Activity or the rule detail to inspect would-run, dispatched, failed, verified, and unresolved outcomes. Pause or revise a rule whose dependencies degrade or whose evidence does not support activation.
What you should see: Activation decisions are based on recorded outcomes rather than the rule definition alone.
If something doesn’t work
A script cannot be selected.
Check that it is enabled, supports the step platform, uses machine context, and is available for the rule trigger.
The rule will not save.
Resolve the displayed scope, step, guardrail, notification, or dependency problem. Reload if the current revision changed.
The rule is degraded or paused.
Open its detail and read the missing dependency or observed failure before resuming.