Automation Triggers
Triggers are the starting point of every automation rule. A trigger defines the event that causes the rule to evaluate its conditions and execute its actions. SetGet provides 10 trigger types that cover the full lifecycle of work items, from creation through state transitions to time-based schedules.
How triggers work
When an event occurs in a SetGet project (for example, a work item's state changes), the automation engine checks all active rules in that project. If a rule's trigger matches the event, the engine evaluates the rule's conditions. If the conditions pass, the rule's actions execute.
The evaluation flow:
- Event occurs in the project.
- Trigger matching: The engine identifies all rules whose trigger type matches the event.
- Condition evaluation: For each matched rule, the engine evaluates conditions against the current state of the work item.
- Action execution: If conditions pass, actions execute in sequence.
TIP
A single event can match multiple rules. All matching rules execute independently. See Advanced Patterns for details on execution order and conflict resolution.
Trigger summary table
| Trigger | Event | Fires when |
|---|---|---|
issue_created | New work item | A work item is created in the project |
issue_updated | Any property change | Any field on a work item changes |
state_changed | State transition | The workflow state of a work item changes |
priority_changed | Priority change | The priority level of a work item changes |
assignee_changed | Assignee modification | Assignees are added or removed |
label_changed | Label modification | Labels are added or removed |
due_date_passed | Due date in the past | A work item's due date is now in the past |
comment_added | New comment | A comment is posted on a work item |
manual | On demand | A user clicks the Run button or calls the API |
scheduled | Time-based | A schedule fires (once, interval, or cron) |
issue_created
Fires when a new work item is created in the project, regardless of how it was created (UI, API, import, or automation).
When it fires
- A team member creates a work item via the UI.
- A work item is created via the SetGet API.
- A work item is created by another automation's action.
- A work item is imported from an external source.
Available data in context
| Field | Description |
|---|---|
issue | The complete work item object at creation time |
issue.state | The initial state assigned to the work item |
issue.priority | The initial priority |
issue.assignees | Initial assignee list (may be empty) |
issue.labels | Initial label list (may be empty) |
issue.created_by | The user who created the work item |
issue.project | The project the work item belongs to |
Example use case
Auto-assign new bugs to the triage lead:
- Trigger:
issue_created - Condition: Label contains "Bug"
- Action: Assign to the designated triage lead
Common patterns
- Auto-assign work items based on type or label at creation.
- Set initial priority based on the creator's role.
- Move newly created items into the current active cycle.
- Send a notification to the project lead when a new work item appears.
- Add a default label to all new work items.
WARNING
Be careful combining issue_created with actions that modify the work item (like changing state). Those modifications can trigger issue_updated or state_changed rules, potentially creating chains. See Advanced Patterns for re-entrancy guards.
issue_updated
Fires when any property on a work item changes. This is the broadest trigger and matches state changes, priority changes, assignee changes, label changes, title edits, description edits, date changes, and any other field modification.
When it fires
- Any field on the work item is modified through the UI, API, or automation.
- Bulk updates trigger this event once per affected work item.
Available data in context
| Field | Description |
|---|---|
issue | The work item after the update |
changes | Object listing which fields changed, with old and new values |
changes.field_name.old | Previous value of the changed field |
changes.field_name.new | New value of the changed field |
actor | The user or system that made the change |
Example use case
Notify the project manager on any change to Urgent items:
- Trigger:
issue_updated - Condition: Priority equals "Urgent"
- Action: Send notification to the project manager
Common patterns
- Audit logging: track every change to high-priority items.
- Notify stakeholders when specific fields change.
- Enforce field requirements (e.g., if due date is removed, re-add it).
TIP
If you only care about a specific field change (like state or priority), prefer the dedicated trigger type (state_changed, priority_changed) instead of issue_updated. Dedicated triggers are more efficient because the engine skips evaluation when unrelated fields change.
state_changed
Fires when the workflow state of a work item transitions from one state to another.
When it fires
- A user drags a work item to a new column on a Kanban board.
- A user changes the state via the work item detail panel.
- An API call updates the state field.
- Another automation changes the state.
Available data in context
| Field | Description |
|---|---|
issue | The work item after the state change |
previous_state | The state the work item was in before the change |
new_state | The state the work item moved to |
state_group | The group of the new state (backlog, unstarted, started, completed, cancelled) |
actor | The user or system that changed the state |
Example use case
Auto-assign QA reviewer when work moves to "In Review":
- Trigger:
state_changed - Condition: New state equals "In Review"
- Action: Assign the designated QA reviewer
Common patterns
- Assign reviewers when work enters review states.
- Notify stakeholders when items move to "Done" or "Cancelled".
- Move completed items to a specific cycle or module.
- Escalate items that move backward (e.g., from "In Progress" back to "Backlog").
- Archive items after they reach a terminal state.
priority_changed
Fires when the priority level of a work item changes.
When it fires
- A user changes the priority via the UI.
- An API call updates the priority field.
- Another automation changes the priority.
Available data in context
| Field | Description |
|---|---|
issue | The work item after the priority change |
previous_priority | The priority before the change (none, low, medium, high, urgent) |
new_priority | The priority after the change |
actor | The user or system that changed the priority |
Example use case
Send an alert when an item is escalated to Urgent:
- Trigger:
priority_changed - Condition: New priority equals "Urgent"
- Action: Send notification to the engineering lead and add the "escalation" label
Common patterns
- Notify leads when items are escalated.
- Auto-assign a senior engineer when priority reaches "High" or "Urgent".
- Add a label indicating the escalation path.
- Move urgent items into the current sprint cycle.
assignee_changed
Fires when assignees are added to or removed from a work item.
When it fires
- A user assigns or unassigns a member via the UI.
- An API call modifies the assignee list.
- Another automation adds or removes an assignee.
Available data in context
| Field | Description |
|---|---|
issue | The work item after the assignee change |
added_assignees | List of users added as assignees |
removed_assignees | List of users removed as assignees |
current_assignees | Complete list of current assignees |
actor | The user or system that changed assignees |
Example use case
Notify the new assignee and move item to "In Progress":
- Trigger:
assignee_changed - Condition: At least one assignee was added AND state is "Backlog"
- Action: Change state to "In Progress", send notification to new assignees
Common patterns
- Automatically transition state when an assignee is added.
- Notify team leads when items are assigned to their team members.
- Enforce assignment limits (notify if a user has too many assignments).
- Log assignment history for workload tracking.
label_changed
Fires when labels are added to or removed from a work item.
When it fires
- A user adds or removes a label via the UI.
- An API call modifies the label list.
- Another automation adds or removes a label.
Available data in context
| Field | Description |
|---|---|
issue | The work item after the label change |
added_labels | List of labels that were added |
removed_labels | List of labels that were removed |
current_labels | Complete list of current labels |
actor | The user or system that changed labels |
Example use case
Route bugs to the triage queue when the "Bug" label is added:
- Trigger:
label_changed - Condition: "Bug" is in added labels
- Action: Change state to "Triage", assign to triage lead
Common patterns
- Route work items to specific workflows based on labels.
- Notify specialized teams when their label is applied (e.g., "Security", "Performance").
- Auto-add related labels (adding "Critical Bug" also adds "Bug").
- Remove conflicting labels automatically.
due_date_passed
Fires when a work item's due date is now in the past and the item is not in a completed or cancelled state.
When it fires
- The system scheduler checks due dates periodically (every 15 minutes).
- If a work item's due date has passed and it is still in an active state group (backlog, unstarted, or started), the trigger fires.
- This trigger fires once per work item per due date crossing. It does not re-fire on subsequent checks.
Available data in context
| Field | Description |
|---|---|
issue | The overdue work item |
due_date | The due date that has passed |
days_overdue | Number of days past the due date |
current_state | The current state of the work item |
assignees | Current assignee list |
Example use case
Escalate overdue items to Urgent priority and notify the project manager:
- Trigger:
due_date_passed - Condition: Priority is not already "Urgent"
- Action: Change priority to "Urgent", send notification to project manager
Common patterns
- Escalate priority of overdue items.
- Notify assignees and managers about overdue work.
- Add an "Overdue" label for visual tracking.
- Post an automated comment noting the item is past due.
WARNING
The due_date_passed trigger runs on a periodic schedule, not in real time. There may be a delay of up to 15 minutes between the due date passing and the trigger firing.
comment_added
Fires when a new comment is posted on a work item.
When it fires
- A user posts a comment via the UI.
- An API call creates a comment.
- Another automation adds a comment (be careful of loops).
Available data in context
| Field | Description |
|---|---|
issue | The work item the comment was added to |
comment | The comment object (text, author, timestamp) |
comment.body | The text content of the comment |
comment.author | The user who posted the comment |
actor | Same as comment author |
Example use case
Notify the assignee when someone comments on their work item:
- Trigger:
comment_added - Condition: Comment author is not the assignee
- Action: Send notification to all assignees
Common patterns
- Notify assignees of new comments.
- Detect keywords in comments (e.g., "blocked", "help needed") and take action.
- Auto-add a label when a comment contains specific text.
- Track comment activity for SLA purposes.
WARNING
If your rule adds a comment as an action, and another rule triggers on comment_added, you can create an infinite loop. Use the re-entrancy guard described in Advanced Patterns.
manual
Fires on demand when a user explicitly triggers the rule via the UI or API. Manual triggers are useful for rules that should not run automatically but need to be available as a one-click action.
When it fires
- A user clicks the Run button on the rule in the Automations settings page.
- A user invokes the rule via the SetGet API
POST /api/automations/{rule_id}/executeendpoint.
Available data in context
| Field | Description |
|---|---|
actor | The user who triggered the rule |
project | The project the rule belongs to |
scope | All work items matching the rule's conditions |
Example use case
Bulk-clean stale items on demand:
- Trigger:
manual - Condition: State is "Backlog" AND updated more than 90 days ago
- Action: Archive all matching work items
Common patterns
- On-demand cleanup of old or stale items.
- Batch operations that should only run when a human decides.
- One-click triage workflows.
- Testing a rule before enabling an automatic trigger.
TIP
Manual triggers are great for testing. Create your rule with a manual trigger first, verify it works as expected, then switch to an automatic trigger type.
scheduled
Fires on a time-based schedule. Scheduled triggers run the rule at specified times regardless of work item events.
When it fires
Three schedule modes are available:
| Mode | Description | Example |
|---|---|---|
| Once | Fires a single time at a specific date and time | March 30, 2026 at 09:00 UTC |
| Interval | Fires repeatedly every N minutes, hours, days, or weeks | Every 24 hours |
| Cron | Fires on a cron schedule | 0 2 * * * (daily at 2:00 AM) |
Available data in context
| Field | Description |
|---|---|
project | The project the rule belongs to |
scope | All work items matching the rule's conditions |
schedule_time | The time the schedule fired |
schedule_type | "once", "interval", or "cron" |
Example use case
Weekly stale item report every Monday at 9 AM:
- Trigger:
scheduled(cron:0 9 * * 1) - Condition: State is "In Progress" AND no update in the last 7 days
- Action: Add "Stale" label, send notification to the project manager
Common patterns
- Daily cleanup of overdue or abandoned items.
- Weekly reports and summaries.
- Monthly archival of completed items.
- Periodic priority reviews.
- Scheduled reminders for items approaching their due date.
For detailed configuration of all three schedule modes, see Scheduling.
Choosing the right trigger
| Scenario | Recommended trigger |
|---|---|
| React to new work items | issue_created |
| React to a specific field change | Use the dedicated trigger (state_changed, priority_changed, assignee_changed, label_changed) |
| React to any change | issue_updated |
| Enforce deadlines | due_date_passed |
| Respond to discussion | comment_added |
| Run on demand | manual |
| Run on a schedule | scheduled |
TIP
Prefer dedicated triggers over issue_updated when possible. Dedicated triggers are more efficient and make rules easier to understand at a glance.
Related pages
- Automation Rules -- Creating and managing rules
- Conditions -- Filtering which items a rule applies to
- Actions -- What happens when a rule fires
- Scheduling -- Configuring scheduled triggers
- Advanced Patterns -- Chaining, loops, and conflict resolution
- Execution History -- Reviewing past rule executions