Documentation
Back to tutorials

Operations

Setting Up and Using Notifications

Create useful notification rules without spamming staff, mixing incompatible event families, or sending blank merge fields.

Who uses it

Managers and operations staff

Where it lives

Dashboard > Notifications and Dashboard > Inbox

Goal

Guilds receive the right alerts in the right place, with useful context and safe delivery behavior.

Before You Start

  • Notification manage permission.
  • At least one destination: channel, staff DM group, user DM topic, or Web Inbox.
  • A specific event you want to react to.

Steps

1

Choose the starting point

Start with the object family: Verifications, Review Queue, Evidence, Support Tickets, RaidHelper, Billing, or Operations. This choice controls which triggers, conditions, and merge fields are relevant.

2

Pick a destination

Use channels for shared staff visibility, staff DMs for urgent role-based alerts, Web Inbox for dashboard triage, and user opt-in DMs for member-specific updates.

3

Use compatible fields

Insert merge fields from the picker for the selected starting point. If the UI warns that a field may be blank or incompatible, change the field or the trigger.

4

Control noise

Set cooldown, dedupe, quiet hours, and scope before enabling. A good rule should be useful when it fires and quiet when nothing needs action.

5

Test and monitor

Send a test notification, then check delivery history and Web Inbox. If delivery fails, check destination health and permissions before editing the rule logic.

Launch Checklist

  • The trigger family matches the fields in the template.
  • Test delivery succeeds or records a clear failure reason.
  • Quiet hours and cooldown are understood by staff.
  • Web Inbox entries can be read and archived.

Common Pitfalls

  • Creating overlapping rules that fire on the same event without dedupe.
  • Using verification fields on support-ticket rules.
  • Sending user DMs without giving users opt-out controls.

Related