Skip to main content
Automation rules run actions when an event or an issue time condition 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.

​
Project automations

Open a project and select Automations beside its other views. The page shows project rules and recurring tasks together. Owners and admins can create, edit, test, enable, disable, and inspect Activity for project rules. Other project members can inspect rule definitions; mutation and Activity controls remain restricted to owners and admins. Create automation fixes the rule scope to the current project and starts at Trigger. The project picker and organization-wide CI trigger are omitted. The empty-state guided flow saves disabled, then offers a dry run and explicit enable. To move a rule to another scope, use Settings → Automations and disable it before changing scope. Organization-wide rules is read-only context. It shows enabled, valid rules for issue events and linked pull-request merges that may also affect this project. Conditions can prevent a match. Organization and project rules run independently; neither overrides the other. Owners and admins can use Manage in Automation Settings to change organization rules. Organization-wide CI rules are not included in this issue-event context. Recurring tasks shows one current occurrence per recurrence chain, with its cadence and task link. Open the task to change recurrence. Completion-triggered recurrence creates the next task when the current occurrence is completed. Scheduled recurrence can create the next task at a saved local wall-clock time; the task detail controls own that schedule and the maintenance sweep fences overlapping workers. This page does not add a second rule store.

​
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 scope

In Settings, explicitly choose one project or Organization-wide. On the project Automations page, scope is fixed to that project and this step is skipped. Name the rule on the Trigger step.
2

Choose a trigger

Select the event that should start the rule, or choose Time-based for inactivity, time in a status, or a time relative to an issue due date. CI run completed is always Organization-wide because it has no source issue or project.
3

Add conditions

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

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

Review and create

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

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

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.

​
Schedule an issue-time rule

Choose Time-based in the existing Trigger step, then select an anchor and an offset in minutes. The available anchors are:
  • Last issue update (updated_at) for inactivity. The offset must be zero or greater.
  • Last status change (status_changed_at) for time in the current status. The offset must be zero or greater. Add a status condition when the rule should apply only to a specific status.
  • Due date (due_date) for a deadline. A negative offset runs before the due date, 0 runs at the due date, and a positive offset runs after it. A date-only due date is evaluated from midnight UTC.
The builder saves this as the existing rule shape with trigger_event: "schedule.issue_time" and a schedule_config object:
Atoll evaluates scheduled rules in the existing maintenance sweep every 15 minutes. Sweeps process bounded batches and rotate through rules, so busy workspaces can take multiple sweeps. Times are not exact to the second. Missed sweeps catch up on a later sweep. Archived issues are excluded. Each (rule, issue, scheduled_for) occurrence is claimed once; a condition mismatch is recorded as a terminal skipped occurrence and is not evaluated again on later sweeps. Scheduled runs use the same conditions, actions, and automation.executed Activity history as event-driven rules. Scheduled rules do not add cron expressions, recurrence rules, calendars, a second rule store, or a separate scheduler dashboard. Completion-mode recurring tasks create their next occurrence when the current task is completed. Scheduled-mode recurring tasks use the saved wall-clock schedule; completing them does not create another occurrence. See Projects and tasks.
Finish later ends the guided continuation but leaves the saved rule disabled. It does not publish or enable the automation.

​
Choose actions

Actions run in order and stop at the first failure. Earlier changes remain saved. You can add a member while keeping other assignees, replace all assignees with one member, clear all assignees, change status or priority, add or remove a label, and post a comment. A change that is already satisfied succeeds without another mutation. Deleted or unavailable references still need correction. Status choices come from the selected project’s board. Organization-wide rules do not have a global status list. Members and labels are saved by their stable IDs, even when their names change. Existing organization-wide rules with source status rows remain visible, but remove or change those rows, or choose a project scope, before saving them in the builder.

​
Create an issue from a rule

Add Create issue and choose its target project. Select an initial status from that project’s current columns; the normal creation default is preselected when available. Enter the title and optional description, priority, assignees, and labels. Each rule can contain one Create issue action. The new issue has its own configuration. For example, if an event on issue A creates issue B, a later Set priority action still changes A. Set B’s priority inside Create issue. Use fixed text with issue triggers. For CI run completed, you can also use {{repository}}, {{workflow}}, {{conclusion}}, and {{run_url}} in the new issue’s content. These values come from the signed GitHub event. To create an issue for an unlinked failed run, select organization scope, choose CI run completed, and use the conditions Conclusion equals failure and Has linked issue equals false. Select the destination project inside Create issue. CI rules support Create issue and Send webhook. Atoll records each repository, run, and attempt once, including its link state. Repeated deliveries use that first record even if issue links later change. A rerun with a new attempt can create a new issue. Completed GitHub push and pull request runs are supported on enabled connections. A repeated delivery cannot create another issue for the same durable action. The Activity Log retains the created issue ID. If creation commits but processing stops before all effects finish, the action is marked failed or uncertain instead of creating another issue. Check the recorded issue before taking manual action. Deleting that issue does not cause automatic recreation. A dry run previews the action without creating an issue. CI previews use fixed example values, not a live run. Custom repository or branch conditions can fail to match that example. Missing required fields on issue previews cause a clear failure. For a time-based rule, the same dry-run endpoint also returns scheduled_for, due, and conditions_matched, then previews the existing actions only when the scheduled time has arrived and all conditions match. It accepts a real issue_id or an issue sample with updated_at, status_changed_at, and due_date; it never changes the issue or creates Activity history.

​
Send a webhook from a rule

Choose Send webhook and select an enabled destination. Use Add webhook to open Webhook Settings in a new tab, with Automation actions only selected. Enter the HTTPS receiver URL and, if required, a Bearer token. Save it, return to your rule, and select Refresh destinations. Your rule draft stays open. Test webhook sends a separate ping. It checks delivery and does not create an automation run or execute the rule. You can save the rule disabled before testing. A destination must have purpose Automation actions only or Both to appear in the action selector. Subscription-only destinations keep their broadcast behavior. In the Activity Log, the action outcome and delivery outcome are separate. An action can finish after a delivery is queued for retry. Its linked delivery then shows the latest attempt, including a later failure. Automatic retries use the same delivery ID. Your receiver must deduplicate this ID before taking an external action. See Outbound webhooks for the payload and authentication contract.

​
Rule validation and change conditions

Atoll validates the complete rule before saving or running it. All conditions must match, and actions run in their listed order. An invalid rule runs no actions, including actions that are valid on their own. An Invalid rule indicator shows why a saved rule cannot run. Select Disable to stop an enabled invalid rule without editing its definition. Only an organization owner or admin can change its state. If the definition has structurally supported conditions and actions, open Edit rule to repair it. An enabled invalid rule must first be disabled with its separate Disable action. Save the repaired definition while it remains disabled, run a new dry run on the saved rule, then select Enable rule. Editing or refreshing the saved rule invalidates an earlier dry run. Rules with malformed or unsupported definitions remain visible for safe API repair. The V1 API supports field comparisons (eq, neq) and change conditions (changed, changed_from, changed_to) for status, priority, and assignee. Change conditions require an issue change trigger. Rules with change conditions remain visible and can be enabled or disabled, but the current builder cannot edit them. Use the API to edit them and provide a canonical event to /test; a sample issue alone cannot show a transition. Existing compatible rules keep their behavior. Missing versions and field kinds normalize to V1 field conditions; supported legacy priority and action values normalize before evaluation. Unsupported versions and malformed definitions stay visible for correction.

​
Review automation history

Open a rule and select Activity Log to review matching automation runs in a compact table. Each row shows the run outcome and start time. Expand a row to inspect the source event, finish time, run and event IDs, attempted actions in order, and safe failure details. Collapse it to return to the run list. 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. For scheduled rules, Activity also shows the normal automation.executed history for matched occurrences. A condition mismatch is recorded as a skipped scheduled occurrence so it is not retried on every sweep. A Loop stopped entry means the same rule revision and relevant issue state were evaluated earlier in the same correlation. This is a skipped run with zero attempted actions. It shows the run, event, correlation, immediate parent event, and earlier run IDs when available. Earlier changes remain committed. Old entries can have no lineage IDs. Internal evaluation fingerprints are never shown.
This foundation release keeps events created by automation actions suppressed. Automatic child-event chaining is not active. It requires a separate reviewed activation after the loop-safe application is live; historical suppressed events will not be replayed.

​
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. Existing terminal or action-bearing run evidence prevents duplicate action execution on redelivery. Only a proven running run with zero action rows can resume. Failed and loop-skipped runs remain terminal. There is no explicit retry action. Arbitrary external side effects do not have an exactly-once guarantee. When another run in the same event blocks replay with terminal or action evidence, an interrupted run with no attempted actions is finalized as failed without executing its actions. If a saved rule changes before an interrupted run resumes, Atoll marks the run failed without executing its actions.