UX Patterns Guide
UI + UX AI And Automation UX emerging

Automation rule builder

Provide a rule authoring flow that separates trigger, condition, branch, action, scope, permission, test, activation, and monitoring state, then require validation and preview evidence before users enable the rule.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users need to create or edit automations that run later based on events, conditions, schedules, or record changes.
  • The product needs safer no-code or low-code authoring for business rules, routing, alerts, approvals, assignments, lifecycle changes, or AI-assisted actions.

Avoid when

  • The user only needs to approve one currently paused automation step.
  • The surface only manages persistent preferences with no future trigger-action execution.
  • The task is a one-time form submission or checklist rather than reusable autonomous behavior.

Problem it prevents

Automation rules can create repeated side effects long after authoring, but builder UIs often hide trigger scope, condition logic, action targets, permissions, test evidence, activation state, conflicts, and runtime safeguards.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Automation rule builder in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

Users may be configuring automations for support routing, notifications, reminders, approvals, assignments, deployments, content publishing, lifecycle state changes, data sync, lead routing, or AI-assisted actions.

Pattern promise

Provide a rule authoring flow that separates trigger, condition, branch, action, scope, permission, test, activation, and monitoring state, then require validation and preview evidence before users enable the rule.

Required state

Empty draft state with rule name, trigger picker, condition builder, action picker, owner, and disabled activation.

Recovery path

The builder hides trigger scope and users enable a rule that runs for every record.

Access contract

Use labelled groups for trigger, condition, branch, action, test, and activation sections.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A support admin creates a rule: When priority is high and sentiment is negative, assign to Escalations, notify the manager, and pause if the customer is VIP; the builder previews matching tickets and lets the admin run a dry test.
  • A workflow rule builder shows trigger, filters, branch, action, target, permission warning, owner, last edited time, and Enable rule only after validation passes.
  • A team lead edits an assignment rule, sees that 18 current tickets would match, tests one sample ticket, notices a conflict with an older VIP rule, resolves priority order, and activates the rule with run logging enabled.
  • A user drafts a reminder rule, leaves it disabled while legal reviews recipient scope, then returns to the same draft with validation errors and unsaved changes preserved.
Weak implementation

Vague, hidden, hard to recover from

  • A page has one text box labelled Automation instructions and an Enable button, with no trigger, condition, action, or test preview.
  • A rule says Send notification on update but hides the fields, recipients, repeat limits, and whether it will run on existing records.
  • A rule activates immediately while the user is still choosing conditions and sends messages to hundreds of customers.
  • Two overlapping automations both update owner fields and the UI never warns about order, loop risk, or duplicate actions.
UI guidance
  • Render automation rule builder as a structured authoring surface with rule name, trigger, scope, conditions, branch logic, actions, recipients or targets, test data, previewed matching records, activation state, run history, and owner.
  • Separate trigger configuration from condition logic and action effects, and show plain-language summaries so users can inspect exactly when the automation runs and what it will change before enabling it.
UX guidance
  • Use automation rule builder when users need to create or edit reusable if/when-then rules that run later without them being present.
  • Make automation safe to activate: validate missing pieces, preview matches, test with sample events, disclose permissions and side effects, handle conflicting rules, and provide pause, draft, rollback, and audit paths.
Implementation contract

What the implementation must handle

States

  • Empty draft state with rule name, trigger picker, condition builder, action picker, owner, and disabled activation.
  • Trigger selected state showing event source, scope, supported fields, repeat behavior, and sample event payload.
  • Condition builder state with groups, AND/OR logic, operators, field types, null handling, and plain-language summary.
  • Action configured state showing target, payload, recipients, permission requirement, side effects, and rollback or undo availability.

Interaction

  • The rule cannot be activated until trigger, condition, action, owner, permissions, and required validation pass.
  • Every rule has a plain-language summary that updates as users edit structured trigger, condition, branch, and action fields.
  • Users can test the rule against sample or real read-only events before activation and see why the rule matched or did not match.
  • Activation is distinct from saving a draft, and edited active rules show whether changes create a new version or update the live rule.

Accessibility

  • Use labelled groups for trigger, condition, branch, action, test, and activation sections.
  • Expose dynamic validation and test results as status messages without moving focus unexpectedly.
  • Ensure add condition, remove row, reorder branch, operator menu, action picker, test, and enable controls are keyboard reachable and named by their rule part.
  • Provide text summaries for visual rule diagrams and connector lines.

Review

  • Can users explain exactly when the rule runs and what it will do before enabling it?
  • Does the builder distinguish save draft from activate rule?
  • Can users test the rule with sample input and inspect why it matched or skipped?
  • Are broad scope, external side effects, permission limits, conflicts, and loop risks visible?
Evidence trail

Source-backed claims behind this guidance

GitHub Actions workflow syntax

GitHub Docs - checked

Supports workflows as configurable automation with events, jobs, steps, dependencies, permissions, and conditions.

Full agent/debug reference

Problem Context

  • Users may be configuring automations for support routing, notifications, reminders, approvals, assignments, deployments, content publishing, lifecycle state changes, data sync, lead routing, or AI-assisted actions.
  • Rules typically combine a trigger event, one or more conditions, optional branches, one or more actions, target objects, timing, repeat limits, owner, permissions, and runtime state.
  • The builder may be no-code, low-code, natural-language assisted, YAML-backed, or form-based, but users still need inspectable semantics before activation.
  • Automation can cause messages, assignments, external calls, status changes, approvals, tickets, alerts, or data updates, so side effects need preview, confirmation, and observability.
  • Rules can overlap, conflict, loop, exceed limits, run outside business hours, fail due to permissions, or become stale after schemas, fields, integrations, or recipient lists change.

Selection Rules

  • Choose automation rule builder when the primary job is authoring a reusable rule with trigger, condition, action, activation, and future runtime behavior.
  • Use human approval gate when automation is already paused at runtime and a human must authorize a specific armed step before it continues.
  • Use approval workflow when a submitted request moves through approver decisions over time rather than defining the rule that creates or routes those requests.
  • Use settings management when users are changing persistent preferences or configuration values, not composing event-condition-action automation.
  • Use complete complex form when the task is a one-time configuration object with dependencies but no future autonomous run behavior.
  • Use recommended next action when the system suggests one optional action in context; use automation rule builder when users define rules that will repeatedly choose or execute future actions.
  • Use notification preferences when users choose delivery channels and frequency; use automation rule builder when they define custom event logic that may send notifications as one action.
  • Expose rule ownership, enabled or disabled state, draft state, trigger source, condition groups, action targets, execution order, and last run before activation.
  • Require preview or test behavior for high-impact actions, broad scope, new rules, edited active rules, natural-language generated rules, or rules that affect external users.
  • Do not use automation rule builder as a broad prompt box, static settings page, hidden cron editor, or opaque AI instruction field.

Required States

  • Empty draft state with rule name, trigger picker, condition builder, action picker, owner, and disabled activation.
  • Trigger selected state showing event source, scope, supported fields, repeat behavior, and sample event payload.
  • Condition builder state with groups, AND/OR logic, operators, field types, null handling, and plain-language summary.
  • Action configured state showing target, payload, recipients, permission requirement, side effects, and rollback or undo availability.
  • Validation error state for missing trigger, invalid operator, unreachable branch, missing permission, dangerous action, or incompatible field.
  • Test run or preview state showing sample input, matched records, branch taken, action preview, skipped action, and expected output.
  • Conflict state showing overlapping rules, priority order, loop risk, duplicate action, rate limit, or stale field dependency.
  • Draft, active, paused, scheduled, failed, disabled, archived, versioned, and last-run states.
  • Natural-language generated rule review state with parsed trigger, conditions, actions, assumptions, and editable structured fields.
  • Mobile compact builder state with rule summary, validation, activation, and run status visible without hiding dangerous effects.

Interaction Contract

  • The rule cannot be activated until trigger, condition, action, owner, permissions, and required validation pass.
  • Every rule has a plain-language summary that updates as users edit structured trigger, condition, branch, and action fields.
  • Users can test the rule against sample or real read-only events before activation and see why the rule matched or did not match.
  • Activation is distinct from saving a draft, and edited active rules show whether changes create a new version or update the live rule.
  • The builder warns about broad scope, external recipients, destructive actions, high-frequency triggers, missing permissions, loops, duplicate actions, and conflicts with other rules.
  • Users can pause, disable, clone, archive, roll back, or inspect run history according to their permission level.
  • Natural-language or AI-authored rules must be converted into inspectable trigger, condition, and action fields before enabling.
  • Runtime failures link back to the rule version, input event, skipped branch, failed action, and recovery path.

Implementation Checklist

  • Model rule name, owner, trigger source, event type, scope, condition groups, operators, values, branches, actions, targets, permissions, enabled state, version, priority, schedule, and run history separately.
  • Provide field-aware condition editors with type-specific operators, null handling, validation, and plain-language summaries.
  • Implement a test runner or dry-run preview that shows sample event input, matched records, branch decisions, actions that would run, and actions skipped.
  • Detect conflicts such as overlapping conditions, priority clashes, loops, duplicate notifications, repeated assignments, broad recipient scope, and stale schema fields.
  • Separate save draft, enable rule, pause rule, disable rule, clone, archive, rollback, and publish changes.
  • Log rule creation, edits, activation, deactivation, test runs, runtime failures, permission failures, and manual overrides.
  • Check accessibility for grouped condition controls, dynamic rows, operator menus, validation summaries, status messages, keyboard reordering, and focus preservation after adding branches or actions.

Common Generated-UI Mistakes

  • Treating a natural-language automation prompt as complete without showing parsed trigger, conditions, and actions.
  • Activating a rule immediately after save without a separate enabled state or preview.
  • Hiding which existing records or future events will match the rule.
  • Using one broad settings toggle for behavior that needs trigger, condition, action, and scope review.
  • Ignoring conflicts between active rules that update the same object or send duplicate notifications.
  • Showing run history without a way to edit, pause, test, or fix the rule.

Critique Questions

  • Can users explain exactly when the rule runs and what it will do before enabling it?
  • Does the builder distinguish save draft from activate rule?
  • Can users test the rule with sample input and inspect why it matched or skipped?
  • Are broad scope, external side effects, permission limits, conflicts, and loop risks visible?
  • Does an active rule have version, owner, run history, pause, rollback, and failure recovery paths?
Accessibility
  • Use labelled groups for trigger, condition, branch, action, test, and activation sections.
  • Expose dynamic validation and test results as status messages without moving focus unexpectedly.
  • Ensure add condition, remove row, reorder branch, operator menu, action picker, test, and enable controls are keyboard reachable and named by their rule part.
  • Provide text summaries for visual rule diagrams and connector lines.
  • Keep focus stable after adding conditions, opening operator menus, running tests, or resolving conflicts.
Keyboard Behavior
  • Tab moves through trigger, condition groups, operator controls, action controls, test controls, and activation controls in logical rule order.
  • Enter or Space activates add, remove, test, save, pause, and enable buttons.
  • Escape closes pickers, menus, and conflict panels without discarding the current rule draft.
  • Arrow keys move within listbox, menu, radio, and segmented controls used by field, operator, branch, and action pickers.
  • Keyboard reordering or explicit move controls are available when rule priority, branch order, or action order affects execution.
Variants
  • If-this-then-that rule builder
  • Trigger-condition-action builder
  • Branching workflow builder
  • Scheduled automation builder
  • Natural-language-to-rule builder
  • Policy rule builder
  • Notification automation rule
  • Assignment routing rule
  • Integration trigger builder

Verification

Source trail checked:

Saved items