create_automation
Create event- or schedule-triggered automation rules on a board to perform actions like moving, assigning, or commenting on tickets.
Instructions
Create an automation rule on a board from a trigger, one to twenty actions, and optional conditions. READ THIS BEFORE CALLING IT: the rule runs as the user this API key acts as, every time it is triggered, for as long as it exists — a standing grant of that person's permissions to anybody who can cause the trigger, not a one-off write like every other tool here, and the resulting history is attributed to them. This one takes effect immediately: the rule is live as soon as it is created and fires on its trigger within a couple of seconds, so do not create one speculatively to see what it would do. Creating one requires a workspace OWNER or ADMIN — a member who can otherwise write on the board is a 403 and retrying cannot fix it. A 402 means the plan's per-board rule limit is already reached (two on free) and nothing was created. Conditions are a flat AND of field/operator/value tests and every one must hold; the operators a field accepts differ, so title contains x is valid where title is x is a 400 listing the operators title takes. run_as_user_uuid defaults to the key's own user, and naming somebody else is refused unless they are an active member who can write and can see the board. Rules arrive switched on unless you pass enabled: false. The schedule and ticket.due triggers are not events and REQUIRE trigger_config: a schedule fans out over every ticket the conditions select at its appointed time, in UTC, so give it conditions unless you really mean the whole board; a due-date rule fires once per ticket per threshold and never retroactively, so creating one does nothing to work that is already overdue. column.empty is the odd one: it is about ONE ticket rather than the board, so it requires a task_uuid alongside trigger_config: {status_uuid}, and it fires the moment that column holds nothing — which may be the moment you create it, since a column that is already empty is already empty. It also keeps doing it every time that column empties again, for ever, unless you pass run_limit; one-off queue entries are what people usually mean, so pass run_limit: 1 unless a standing arrangement was actually asked for. create_linked_ticket is the exception to all of that: it CREATES a ticket rather than changing the triggering one, it needs a title (templated, so {{now}} makes a weekly checklist a new ticket each week) and takes an optional description, status_uuid and relationship (blocks, blocked_by, related_to, duplicate_of, stated from the new ticket's point of view). A schedule rule whose actions are ONLY this fires once for the board rather than once per ticket, which is what makes "every Monday, create the release checklist" work — and such a rule is refused if it also carries conditions, a relationship, or any action that acts on a ticket, because none of those has a ticket to be about. A ticket-triggered rule using it feeds itself, and is stopped by the depth cap after three chained runs rather than looping.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| actions | Yes | Each action is an object with a `type` from the list and whatever that action needs — a status, a user, a label, a comment body | |
| enabled | No | ||
| run_limit | No | column.empty only, and every other trigger refuses it. How many times the rule may move the ticket before it retires itself: a ticket can leave that column and the column can empty again, and without a limit the rule pulls it back in every time, indefinitely. Pass 1 unless a standing arrangement is what was actually asked for. A finished rule comes back from list_automations switched off with a `disabled_reason` saying so, and switching it back on does not give it more runs. Counts the runs that acted, successes and failures alike. Cannot be changed afterwards | |
| task_uuid | No | column.empty only, where it is required: the ticket the rule moves. Every other trigger refuses it, since those act on the ticket that set them off. Cannot be changed afterwards — a rule about the wrong ticket has to be deleted and made again | |
| board_uuid | Yes | The board's uuid, from list_boards | |
| conditions | No | A flat AND — every condition must hold. No OR and no nesting. Omit for every occurrence of the trigger | |
| trigger_type | Yes | ||
| trigger_config | No | Required for the schedule, ticket.due, ticket.in_column and column.empty triggers and ignored by every other one. A schedule needs {interval, at}; a due-date rule needs {when} plus {days} unless when is "arrives"; a dwell rule needs {status_uuid, days}; a column.empty rule needs {status_uuid}. | |
| run_as_user_uuid | No | Defaults to the user this key acts as. Read the warning above |