Automation rule builder

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?