Automations: rules that work for you

Automations take the routine out of board-keeping: assign new bugs, chase stale work, move unfinished cards to the next sprint. Rules live at workspace level on the Automations page (in the sidebar's Administration section), with a + New rule button, a searchable rule list showing each rule's on/off state and success and error counts, and tabs for Templates, the rule editor and the Run log.

How a rule is built

The rule builder has three steps: When this happens (the trigger), If (optional — all must pass) (conditions), and Then (ordered) (actions, which you can reorder and remove). A rule can be scoped to a single board or left org-wide — the board picker's default reads All boards (org-wide).

• Triggers cover a wide array of events, including: When an issue is created, When status changes, When priority changes, When someone is assigned, When due date is approaching, When the due date passes, After N days of inactivity, When a tag is added, When a comment is posted, When a sprint starts, When a sprint ends, On a schedule, and When a webhook arrives.
• Conditions are all ANDed and include status-bucket checks, priority thresholds, assignee membership, tags, issue types, effort thresholds, recency, no-assignee, sprint membership, the acting user's role, and comment-body matching.
• Actions include: Assign the issue, Change status, Set priority, Add or Remove a tag, Set effort points, Set due date, Set sprint, Set epic, Add a comment, Notify participants, Send email, Post to webhook, Create sub-issue, Create linked issue in board, Archive issue, and Mirror to another board.

Actions run in order and are best-effort: if one action fails, the failure is recorded but earlier actions are not rolled back. Text fields accept template variables such as {{trigger.issue_id}} and {{rule.rule_name}}.

Schedules and inbound webhooks

On a schedule rules offer Daily, Weekly and Monthly cadences and fire with minute granularity. When a webhook arrives gives the rule its own inbound URL and token; external systems must sign the request body with HMAC in the x-laya-signature header, and unsigned or badly signed requests are refused.

Start from a template

The Templates tab ships ready-made recipes — among them “Auto-assign new bugs to the on-call”, “Close stale issues”, “Notify when high-priority is unassigned”, “Move incomplete to next sprint”, “Auto-tag stuck issues” and “Welcome new participants”, plus a set of AI Agent templates for supervising agent-driven work. Loading one shows “Template loaded — fill in the placeholders before saving.” — templates deliberately ship with placeholders you must replace.

Testing and the Run log

Two manual run buttons help you trust a rule before it runs unattended: Run now (test mode) performs a dry run (“Dry run passed.”), and Run now fires it for real (“Rule fired.” or “Rule ran with errors.”). Every run — automatic or manual — lands in the Run log with its timestamp, trigger, success flag, the conditions evaluated (pass or reason) and each action's outcome. Deleting a rule removes the rule and its run history, and asks you to confirm first.

Who a rule acts as

A rule runs with its author's current authority, re-checked on every run. If the author leaves the workspace, the rule stops. If the author loses automations:manage, the rule stops running entirely. If the author keeps that capability but loses a specific right — say, archiving — then only the actions they could no longer perform by hand stop executing. On manual runs, every action must be permitted for both the author and the person clicking run.

Practical recipes

• Keep the sprint honest — When a sprint ends → If status bucket is not Done → Set sprint (next sprint) and Add a comment.
• Escalate silent urgent work — After N days of inactivity → If priority is at least Urgent → Notify participants.
• Route incoming bugs — When an issue is created → If it has the issue type Bug → Assign the issue and Set priority.