Alert Triggers

Triggers are the core mechanism of the SetGet alert system. A trigger defines which event should generate a notification, which template to use for formatting, and who should receive the notification. When the specified event occurs and any configured conditions are satisfied, the system dispatches notifications through the channels enabled in each recipient's preferences.

How triggers work

The trigger evaluation flow is:

1. A user or system action modifies a work item (e.g., changes state, adds a comment, updates priority).
2. The backend NotificationDispatcher fires the corresponding event.
3. The alert system evaluates all active triggers that match the event type.
4. For each matching trigger, conditions are checked against the work item's current properties.
5. If conditions pass, the system resolves the recipient list.
6. For each recipient, the system checks their notification preferences to determine which channels are enabled.
7. Notifications are dispatched through the enabled channels (in-app, email, SMS) using the configured template.

Event types reference

SetGet supports 16 event types that can be used as trigger sources. Each event type corresponds to a specific action on a work item or its related entities.

Event type	Fires when	Typical use case
state_changed	A work item's state is updated (e.g., "Todo" to "In Progress")	Notify assignees and watchers about workflow progression
assignee_changed	A work item is assigned to a different user or unassigned	Alert the new assignee about their new responsibility
priority_changed	A work item's priority level is changed	Escalate awareness when priority increases to Urgent or High
comment_added	A new comment is posted on a work item	Keep subscribers informed about discussion activity
issue_created	A new work item is created in the project	Notify project leads about incoming work
due_date_passed	A work item's due date has elapsed without completion	Alert assignees and managers about overdue items
label_changed	Labels are added to or removed from a work item	Notify label owners when their area is affected
property_changed	Any tracked property on a work item is modified	Catch-all for property updates not covered by specific events
issue_completed	A work item transitions to a completed state	Notify stakeholders that deliverables are ready
mentioned	A user is @mentioned in a comment or description	Deliver a targeted notification to the mentioned user
date_changed	A work item's start date or due date is modified	Alert planners when schedules shift
cycle_changed	A work item is added to or removed from a cycle	Notify cycle leads about scope changes
module_changed	A work item is added to or removed from a module	Notify module owners about scope changes
link_changed	A link is added to or removed from a work item	Inform collaborators about new external references
relation_changed	A relation (blocks, is blocked by, relates to) is added or removed	Alert dependent teams about relationship changes
archive_changed	A work item is archived or unarchived	Notify the team when items are removed from or restored to active view

TIP

The property_changed event is a broad catch-all. If a more specific event type exists for the property you care about (e.g., priority_changed for priority), use the specific event type for cleaner trigger logic.

Event categories

The 16 event types fall into four logical categories:

Core lifecycle events

These events track the fundamental lifecycle of a work item from creation to completion and archival.

Event	Category
issue_created	Creation
state_changed	Workflow progression
issue_completed	Completion
archive_changed	Archival

Property change events

These events fire when specific properties on a work item are modified.

Event	Property
assignee_changed	Assignee
priority_changed	Priority
label_changed	Labels
date_changed	Start date or due date
property_changed	Any other tracked property

Collaboration events

These events relate to human interaction on work items.

Event	Interaction
comment_added	New comment posted
mentioned	User @mentioned

Relationship events

These events fire when a work item's relationships to other entities change.

Event	Relationship
cycle_changed	Cycle membership
module_changed	Module membership
link_changed	External links
relation_changed	Work item relations (blocks, relates to, etc.)

Time-based events

Event	Condition
due_date_passed	Due date has elapsed (evaluated on a background schedule)

WARNING

The due_date_passed event is evaluated by a background scheduler, not by a user action. It fires once when the due date passes. If you need recurring reminders, create multiple triggers with different conditions or use the automation system.

Creating a trigger

Step 1: Navigate to triggers

1. Open your workspace.
2. Go to Settings > Reminders > Triggers.
3. Click Create Trigger.

Step 2: Select the event type

Choose one of the 16 event types from the dropdown. This determines which actions will cause the trigger to fire.

Consider which event most precisely matches your notification need. For example, if you want to notify people when a work item is marked as a blocker, use priority_changed with a condition that filters for the "Urgent" priority level, rather than the generic property_changed event.

Step 3: Choose a template

Select the email template to use for formatting the notification. SetGet provides 21 system templates organized by category. The template determines the subject line, body structure, and variable placeholders used in the notification.

Each event type has a natural template match:

Event type	Recommended template
state_changed	State Change
assignee_changed	Assignment
priority_changed	Priority Alert
comment_added	Comment Added
issue_created	Issue Created
due_date_passed	Due Date Overdue
label_changed	Label Changed
issue_completed	Issue Completed
mentioned	Mention
date_changed	Date Changed
cycle_changed	Cycle Issue Added
module_changed	Module Issue Added
link_changed	Link Updated
relation_changed	Relation Changed
archive_changed	Issue Archived
property_changed	Property Change

See Templates for the full template catalog and variable reference.

Step 4: Select recipients

Define who should receive the notification when this trigger fires. You can combine multiple recipient types.

Recipient type	Description
Assignees	The current assignee(s) of the work item
Creator	The user who originally created the work item
Subscribers	All users who have subscribed to the work item
Specific users	One or more workspace members selected by name

Recipient resolution rules:

• If a user appears in multiple recipient types (e.g., they are both the assignee and a subscriber), they receive only one notification per channel.
• The actor who caused the event is excluded from notifications by default. For example, if a user changes the state of their own work item, they do not receive a state change notification.
• Specific users always receive the notification regardless of their subscription status.

Step 5: Set conditions (optional)

Conditions narrow the scope of the trigger so it fires only for work items that match specific criteria. Without conditions, the trigger fires for every occurrence of the selected event in the workspace.

Available condition fields:

Condition field	Operators	Example
Project	is, is not	Only fire for work items in the "Backend" project
State	is, is not	Only fire when the new state is "In Review"
Priority	is, is not, greater than, less than	Only fire when priority is Urgent or High
Label	contains, does not contain	Only fire for items labeled "Bug"
Assignee	is, is not	Only fire for items assigned to a specific user

Conditions are evaluated with AND logic --- all conditions must be true for the trigger to fire.

TIP

Use conditions to prevent noise. A state_changed trigger without conditions fires on every state transition in the workspace. Adding a condition like "State is In Review" limits notifications to a single meaningful transition.

Step 6: Activate the trigger

Review your configuration and click Save. The trigger is created in an active state by default and begins processing events immediately.

Managing triggers

Viewing triggers

The Triggers page displays all configured triggers in a table with the following columns:

Column	Description
Name	Auto-generated from the event type and template
Event	The event type that activates this trigger
Template	The email template used for formatting
Recipients	Summary of recipient types
Conditions	Number of active conditions
Status	Active or Disabled
Created	Creation date

Editing a trigger

1. Click on any trigger row to open the detail view.
2. Modify the event type, template, recipients, or conditions.
3. Click Save to apply changes.

Changes take effect immediately for new events. Events that were already dispatched before the edit are not affected.

Enabling and disabling triggers

To temporarily stop a trigger from firing without deleting it:

1. Click the toggle switch in the Status column.
2. The trigger changes to Disabled and stops processing events.
3. Toggle again to re-enable.

Disabled triggers are preserved with their full configuration. No notifications are sent while a trigger is disabled.

Deleting a trigger

1. Click the delete icon on the trigger row.
2. Confirm the deletion in the dialog.

WARNING

Deleting a trigger is permanent and cannot be undone. If you might need the trigger again, disable it instead.

Trigger examples

Example 1: Notify the team lead when a blocker is created

Goal: When any work item's priority is changed to Urgent, notify the engineering lead immediately.

Setting	Value
Event type	priority_changed
Template	Priority Alert
Recipients	Specific users: Engineering Lead
Conditions	Priority is Urgent

Example 2: Remind assignees about overdue items

Goal: When a work item's due date passes, notify the assignee and the project creator.

Setting	Value
Event type	due_date_passed
Template	Due Date Overdue
Recipients	Assignees, Creator
Conditions	None (applies to all overdue items)

Example 3: Notify reviewers when work enters review

Goal: When a work item transitions to the "In Review" state, notify specific reviewers.

Setting	Value
Event type	state_changed
Template	State Change
Recipients	Specific users: Reviewer A, Reviewer B
Conditions	State is "In Review"

TIP

This scenario is also a good candidate for a State mapping, which provides a more intuitive interface for state-to-state transition alerts.

Example 4: Keep module owners informed about scope changes

Goal: When a work item is added to the "Authentication" module, notify the module owner.

Setting	Value
Event type	module_changed
Template	Module Issue Added
Recipients	Specific users: Auth Module Owner
Conditions	None

Example 5: Alert on new bugs

Goal: When a new work item is created with the "Bug" label, notify the QA team.

Setting	Value
Event type	issue_created
Template	Issue Created
Recipients	Specific users: QA Lead, QA Engineer
Conditions	Label contains "Bug"

Example 6: Notify stakeholders when work is completed

Goal: When any work item reaches a completed state, notify the creator and all subscribers.

Setting	Value
Event type	issue_completed
Template	Issue Completed
Recipients	Creator, Subscribers
Conditions	None

Trigger execution order

When multiple triggers match the same event, they all fire independently. There is no priority or ordering between triggers. Each trigger evaluates its own conditions and dispatches to its own recipient list.

If a user would receive multiple notifications for the same event from different triggers, the system deduplicates at the channel level --- the user receives one notification per channel, using the template from the first matching trigger.

Performance considerations

• Each active trigger adds evaluation overhead to every matching event. Keep the number of active triggers reasonable for your workspace size.
• Use conditions to narrow trigger scope rather than creating many broad triggers.
• The property_changed event fires frequently. Use it with specific conditions to avoid excessive notifications.
• The due_date_passed event is evaluated on a background schedule and does not add real-time processing overhead.

Trigger audit and maintenance

Over time, triggers can become stale as projects evolve, team members change roles, and workflows are restructured. Regular maintenance keeps your trigger set effective.

Quarterly review checklist

• [ ] List all active triggers and verify each one still serves a purpose.
• [ ] Check that "specific user" recipients still hold the relevant role (e.g., a reviewer who moved to a different team).
• [ ] Review the History page for triggers that have not fired in 30+ days --- they may be obsolete.
• [ ] Verify that conditions still match current project states, labels, and priorities.
• [ ] Disable triggers that are no longer needed rather than leaving them active.

Identifying noisy triggers

A noisy trigger fires too often and generates more notifications than are useful. To identify noisy triggers:

1. Go to Workspace Settings > Reminders > History.
2. Sort by trigger and count sends per trigger over the last 7 days.
3. If a trigger is responsible for more than 30% of all notifications, review its conditions.

Common fixes for noisy triggers:

Problem	Fix
No conditions set	Add conditions to narrow scope
Broad event type (property_changed)	Switch to a more specific event type
Recipients include all workspace members	Narrow to Assignees, Creator, or specific users
Trigger covers all projects	Add a project condition

Limits

Limit	Value
Maximum triggers per workspace	100
Maximum conditions per trigger	10
Maximum specific user recipients per trigger	50
Maximum recipient types per trigger	All 4 types can be combined

Related pages

• Alerts overview --- Introduction to the alert system
• Templates --- Email template catalog and variable reference
• State mappings --- State-to-state transition alerts
• Notification preferences --- Per-user channel configuration
• Alert history --- View send logs and delivery status
• Best practices --- Design an effective notification strategy
• Automations --- Trigger-action rules for automated workflows