Features · Automation
Automation without a scripting degree
Triggers, conditions, actions — rules that respect your workflow.
Automation rules watch ticket activity in your project and act on it. When a trigger fires and every condition matches, the rule's actions run — after the triggering change commits, in a separate transaction, with each outcome logged to a run history. Rules are built from plain parts: one trigger or schedule, zero or more conditions, one or more actions.
What you get
- Six trigger events — fire a rule when a ticket is created, updated, its status changes, its assignee changes, a comment is added, or a label is added.
- Five condition fields — narrow the match by type, priority, status, label, or a due date within the next N days — a rule applies only when all of its conditions hold.
- Six actions — in the rule builder: assign, set priority, transition, add label, add comment, or add a canned comment from a saved template.
- Runs after commit — so a rule sees the ticket as it was actually saved; execution happens in its own transaction and never blocks or breaks the change that triggered it.
- Workflow-validated transitions — mean a transition action only moves a ticket along a path the project's workflow allows for that ticket type; anything else is skipped, not forced.
- A run history — records each matching run as applied, skipped, or failed — with an error message on failure — so your admins can review a rule's recent activity.
See it
Loop-proof by design
Rule actions modify tickets directly instead of re-publishing change events, so automation can never trigger itself into a loop. The label-added trigger fires only when a person attaches a label; a rule's own add-label action does not re-trigger it. If one action in a rule fails, the remaining actions still run, and the failure is logged rather than swallowed.
Scheduled and global rules
A rule can run on a clock instead of an event: hourly or daily, useful with the due-within condition for deadline sweeps. On multi-node deployments each due run is claimed with a compare-and-set update, so exactly one backend executes it. Org admins can also define global rules that apply across every project, using a deliberately restricted vocabulary — type, priority, and due-within conditions; assign, set-priority, and add-comment actions — with runs logged under each affected project.
Attributed and audited
Assignments, priority changes, transitions and comments made by a rule all land in the ticket's change history. Comments added by a rule default to internal notes; on service-desk tickets a rule can mark a comment customer-visible, which posts it as a public reply and emails the requester. Creating, updating, or deleting a rule is itself recorded in the configuration audit log.
In practice
POST /api/v1/projects/{projectKey}/automation-rules
{
"name": "Triage bugs",
"enabled": true,
"trigger": "CREATED",
"conditions": [{ "field": "TYPE", "value": "BUG" }],
"actions": [{ "type": "SET_PRIORITY", "value": "HIGH" }]
}See Iskue on your own screen
A demo takes half an hour. A pilot runs on your servers, with your data, from day one.