Skip to main content
Automation rules run actions when an event matches their trigger and optional conditions. Open Settings → Automations to create and manage rules. You must be an organization owner or admin to access automation settings.

​
Create your first rule

Choose Guide me through my first rule when no rules exist, or Guided setup from the rules page.
1

Choose a trigger

Name the rule and select the event that should start it.
2

Add conditions

Narrow which matching events qualify. You can continue without conditions when every event should qualify.
3

Add actions

Choose at least one action for Atoll to perform when the rule matches. If the rule posts a comment, the comment is attributed to Automation; the rule creator remains the authorization member, not the comment author.
4

Review and create

Review the trigger, conditions, and actions. Guided setup always creates the rule disabled, so saving it cannot start live automation.
5

Run a dry run

Test the exact newly created rule. A dry run evaluates the rule without enabling it. If you edit the rule afterward, run a new dry run because the earlier result no longer applies.
6

Enable explicitly

Select Enable rule only after a successful dry run. The rule remains disabled if enabling fails, and you can retry from the same rule card.
Finish later ends the guided continuation but leaves the saved rule disabled. It does not publish or enable the automation.

​
Review automation history

Open a rule and select Activity Log to review matching automation runs. Each entry shows the source event, run outcome, start and finish times, attempted actions in order, and safe failure details when an action fails. Non-matching events, dry runs, and rules with no executable actions do not create history entries. Action inputs, request payloads, credentials, and other secret values are not shown. If a definitive action-audit start fails after an earlier action, the run is terminal with safe error_code: "automation_execution_partial" and message automation execution stopped after one or more earlier actions; earlier action evidence is not replayed. Deleting a rule or its project preserves its run and action history with the original rule UUID; deleting the organization may remove organization-owned history.

​
Recover from an interrupted setup

  • If Atoll returns a definite creation error, correct the error and retry.
  • If the create request loses its response or Atoll cannot read a successful response, do not resubmit it. The rule may already exist; reload the page and inspect the rules list before creating another rule. This avoids duplicates.
  • If the new rule card cannot be found after refresh, reload the page. No rule is enabled automatically.
  • If a dry run fails or returns an invalid result, retry it. Enablement stays unavailable until the exact current rule has a successful result.
  • If enablement fails, the rule remains disabled.
You can also choose New rule for the standard builder. That path preserves the existing rule behavior and does not add the guided disabled-create and dry-run continuation.

​
Event processing and retries

Atoll persists a matching issue event before it evaluates automation rules. A worker claims the event and renews its claim while rule actions run. Transient processing failures retry with bounded backoff. If Atoll observes that an action may have run but its result cannot be verified, it marks the event failed instead of retrying that observed failure and risking a duplicate side effect. Invalid event payloads also fail closed. If a worker terminates after an action commits but before the event is finalized, the expired event claim can be reclaimed. Comment actions have no action-level idempotency key, so event processing does not promise exactly-once delivery.