Alert Best Practices

A well-designed notification strategy keeps your team informed without overwhelming them. Too few alerts and critical updates are missed. Too many and people start ignoring notifications entirely. This guide covers practical recommendations for building a notification system that your team will trust and rely on.

Designing your trigger strategy

Classify events by urgency

Not every event deserves the same notification treatment. Start by categorizing your 16 available event types into three tiers:

Tier	Urgency	Recommended channels	Example events
Critical	Requires immediate action	In-app + Email + SMS	due_date_passed, priority_changed (to Urgent)
Important	Should be seen within hours	In-app + Email	state_changed, assignee_changed, mentioned, comment_added
Informational	Nice to know, no urgency	In-app only	label_changed, property_changed, link_changed, archive_changed

This tiered approach ensures that the most urgent events get the most attention while lower-priority updates stay available without creating noise.

Start with fewer triggers

When setting up alerts for the first time, resist the temptation to create triggers for every event type. Start with a small set of high-value triggers and expand based on team feedback.

Recommended starting triggers:

1. due_date_passed --- Notify assignees about overdue work items.
2. state_changed with condition "State is In Review" --- Notify reviewers when work is ready.
3. mentioned --- Notify users when they are mentioned in comments.
4. assignee_changed --- Notify the new assignee about their assignment.

These four triggers cover the most common pain points: missed deadlines, review bottlenecks, ignored mentions, and unacknowledged assignments. Add more triggers only when the team identifies specific gaps.

Use conditions to narrow scope

A trigger without conditions fires on every matching event in the workspace. This is almost never what you want. Use conditions to target the notifications that matter:

Instead of...	Use...
state_changed with no conditions (fires on every state change)	state_changed with condition "State is In Review" (fires only when work enters review)
priority_changed with no conditions (fires on every priority change)	priority_changed with condition "Priority is Urgent" (fires only on critical escalations)
issue_created with no conditions (fires on every new work item)	issue_created with condition "Label contains Bug" (fires only for new bugs)

Prefer specific events over generic ones

The property_changed event fires on almost any modification to a work item. It is useful as a catch-all but generates significantly more notifications than targeted events. When a specific event type exists for the property you care about, use it:

Generic approach	Better approach
property_changed with condition "Priority changed"	priority_changed
property_changed with condition "Assignee changed"	assignee_changed
property_changed with condition "State changed"	state_changed

Reserve property_changed for edge cases that are not covered by the 15 specific event types.

Avoiding notification fatigue

Notification fatigue is the primary risk of any alert system. When users receive too many notifications, they develop "notification blindness" and stop paying attention to alerts, including critical ones.

Signs of notification fatigue

• Team members disable email or SMS for most events.
• The notification panel (bell icon) consistently shows high unread counts.
• Users report ignoring notifications because "there are too many."
• Important alerts are missed despite being correctly delivered.

Prevention strategies

1. Fewer triggers is better than more triggers. Each additional trigger increases the notification volume across the workspace. Every trigger should have a clear justification.

2. Use recipient targeting, not broadcast. Avoid triggers that notify all workspace members. Target notifications to the people who need to act: assignees, creators, or specific role holders.

Approach	Volume impact
Recipients: All workspace members	High (N notifications per event, where N = member count)
Recipients: Assignees + Creator	Low (1-3 notifications per event)
Recipients: Specific users (role-based)	Low (1-5 notifications per event)

3. Let users control their preferences. Remind team members that they can disable channels for events they do not find useful. The preferences page gives each user full control over their notification experience.

4. Audit trigger volume periodically. Review the History page monthly. If a single trigger is responsible for a disproportionate share of notifications, consider adding conditions to narrow its scope or disabling it.

5. Disable rather than delete. If a trigger is generating too much noise, disable it temporarily and observe whether the team misses the notifications. If no one notices, the trigger was not providing value.

SMS usage recommendations

SMS is the most disruptive notification channel. A phone buzzing with a text message demands immediate attention in a way that email and in-app notifications do not. Use it with care.

When to use SMS

Scenario	Appropriate for SMS
Work item is overdue and assigned to you	Yes
A blocker is created on your work item	Yes
Priority escalated to Urgent on a critical-path item	Yes
A comment was added to a work item you follow	No
A label was changed on a work item	No
A new work item was created in your project	No

SMS guidelines

• Limit SMS to 1-3 event types per user. If a user has SMS enabled for more than three event types, they are likely over-notified.
• Combine SMS with conditions. Do not send SMS on every priority_changed event --- only when the new priority is Urgent.
• Respect personal time. SMS notifications arrive at any hour. If your team spans multiple time zones, be mindful of which events trigger SMS.
• Monitor SMS costs. Each SMS message has a cost (Twilio or your webhook provider). High-volume SMS can become expensive. Review SMS volume in the History page regularly.

Recommended SMS configuration

Event type	SMS recommended	Condition
due_date_passed	Yes	Assignee only
priority_changed	Yes	Only when priority is Urgent
state_changed	Situational	Only for blocker states
All other events	No	---

State mapping patterns

State mappings are powerful for workflows with well-defined stages. Here are patterns that work well in practice.

Linear review pipeline

For teams with a linear workflow (Development to Review to QA to Done):

From state	To state	Recipients	Purpose
In Progress	In Review	Code reviewers	Reviewer pickup
In Review	QA Testing	QA team	QA pickup
QA Testing	Ready for Deploy	DevOps lead	Deploy queue awareness
Any	Done	Creator, Subscribers	Completion notification

Escalation pattern

For teams that need escalation when items become blocked:

From state	To state	Recipients	Purpose
Any	Blocked	Assignee, Project manager	Immediate escalation
Blocked	In Progress	Assignee	Blocker resolved confirmation

Release management

For teams managing release cycles:

From state	To state	Recipients	Purpose
Any	Ready for Release	Release manager	Release candidate queue
Ready for Release	Released	Creator, Subscribers	Release confirmation

Keep mappings focused

• Create mappings only for transitions that require human action or awareness.
• Not every state transition needs a mapping. Routine transitions (e.g., "Backlog" to "Todo") rarely warrant a notification.
• If you find yourself creating mappings for every possible transition, you are likely over-configuring. Focus on the transitions where notification adds value.

Template usage tips

SetGet provides 21 system templates. Here are tips for using them effectively:

Match templates to context

Always use the most specific template for each trigger. The State Change template includes previous and new state context that the generic Property Change template lacks. Similarly, the Priority Alert template highlights the priority level change prominently.

Preview before activating

Always preview templates with sample data before activating a trigger. Verify that the subject line, body, and variable substitution produce a clear and actionable notification.

Test with real recipients

Send a test notification to yourself before going live. This catches formatting issues, broken links, and delivery problems that preview alone cannot reveal.

Keep the action clear

The best notifications have a single clear action: "Review this work item," "Resolve this blocker," "Deploy this release." If a notification does not suggest a clear action, it is likely informational and should use in-app only.

Monitoring delivery health

A notification system is only useful if notifications are actually delivered. Monitor delivery health proactively.

Key metrics to watch

Metric	Healthy range	Warning sign
Success rate (from dashboard)	95%+	Below 90% indicates a systemic delivery issue
Failed sends per day	0-5	More than 10 suggests a configuration problem
Pending sends older than 5 minutes	0	Any pending send older than 5 minutes indicates a queue issue
SMS failure rate	Below 5%	Higher rates suggest phone number or provider issues

Weekly review checklist

Perform a brief weekly review of your alert system health:

• [ ] Check the stats dashboard for success rate trends.
• [ ] Filter History by Status: Failed for the past week.
• [ ] Investigate any recurring failure patterns (same recipient, same channel, same error).
• [ ] Verify that SMS balance (Twilio) is sufficient for the coming week.
• [ ] Ask team members if they are receiving notifications as expected.

Responding to delivery issues

When you detect delivery problems:

1. Isolate the channel. Are failures on email, SMS, or both?
2. Check credentials. SMTP and SMS provider credentials may have expired or been rotated.
3. Send a test. Use the template test feature to confirm the channel is working.
4. Check the provider. For email, check SMTP server status. For SMS, check Twilio dashboard or webhook endpoint health.
5. Review recent changes. Did someone change SMTP settings, SMS provider, or network configuration?

Scaling considerations

As your workspace grows in members and work items, the notification volume scales proportionally. Plan for this growth.

Volume estimation

Workspace size	Estimated daily events	Estimated notifications (with targeting)
5-10 members	50-200 events	100-500 notifications
10-50 members	200-1,000 events	500-3,000 notifications
50-200 members	1,000-5,000 events	3,000-15,000 notifications
200+ members	5,000+ events	15,000+ notifications

Scaling tips

• Tighten conditions as team grows. Broad triggers that worked for a 10-person team may generate unbearable volume for 50 people.
• Use role-based recipients. Instead of adding many specific users, use recipient types (Assignees, Creator, Subscribers) that automatically target the right people.
• Review trigger count. A workspace should rarely need more than 20-30 active triggers. If you have more, look for consolidation opportunities.
• Monitor queue processing time. If the gap between "Pending" and "Sent" timestamps in History grows, the notification queue may need attention.

Common mistakes to avoid

Mistake	Why it is a problem	What to do instead
Creating a trigger for every event type	Notification flood, users ignore everything	Start with 4-5 high-value triggers and expand based on need
Using "All workspace members" as recipients	Everyone gets notified for everything	Target Assignees, Creator, or specific role holders
Enabling SMS for informational events	Disrupts users unnecessarily, incurs cost	Reserve SMS for critical and urgent events only
Not testing templates before activation	Broken formatting or delivery discovered in production	Always preview and send a test before going live
Ignoring the History page	Delivery failures go unnoticed	Review History weekly for failed sends
Creating duplicate triggers for the same event	Users receive multiple notifications for one event	Consolidate into a single trigger with combined recipients
Never reviewing trigger effectiveness	Stale triggers generate noise without value	Audit triggers quarterly and disable unused ones

Related pages

• Alerts overview --- Introduction to the alert system
• Triggers --- Configure event-based notification triggers
• Templates --- Email template catalog and variable reference
• State mappings --- State-to-state transition alerts
• SMS configuration --- Set up SMS delivery providers
• Notification preferences --- Per-user channel configuration
• Alert history --- View send logs and delivery status
• Automations --- Trigger-action rules for automated workflows