Skip to main content
Notification rules decide who hears about what. When something happens in your workspace — a time-off request is added, a new lead comes in, a customer signs a proposal — a notification rule looks at that event and works out which people should be told. Each rule pairs one kind of event with a set of recipients, so the right team members stay in the loop without everyone getting pinged about everything.
Notification rules live under Settings → Notifications → Rules, where workspace admins manage them directly. Open a rule to change its recipients, adjust who can trigger it, or turn it on or off, then save. If you don’t see the Notifications area in Settings, you don’t have the workspace-admin access it requires — ask an admin to make the change. Rules apply to your whole workspace. The Notifications and Shift Reminders tabs next to it are set per branch and control how notifications are sent — see Notification preferences.

​
What a rule is made of

Every rule answers three questions:
  • Which event triggers it? The thing that happens — for example, Time Off Added or Proposal signed by client.
  • Who should be notified? The recipients, chosen by role, by branch, or as specific people.
  • Is it on? A single switch turns the whole rule on or off.
A rule can also be limited to events started by certain people (for example, only fire when a salesperson is the one who acted), so you can keep notifications relevant to how your team actually works.

​
The events you can notify on

Each rule is tied to one event. The events available today, in the order they appear on the Rules tab, are:
  • Lead Ingested — a new lead gets assigned to a branch.
  • Proposal signed by client — a customer signs a proposal.
  • Competing proposals uploaded — a customer uploads competing proposals for your team to see.
  • Job plan submitted for review — a job plan is submitted and waiting for someone to review it.
  • Job plan changes required — changes are required on a submitted job plan.
  • Event not published — 48 hour reminder — an event is still unpublished 48 hours before it’s scheduled to start, so a reminder goes out.
  • Time Off Added — a team member adds a time-off request.
  • Texting approved — your workspace’s texting number is approved and texting goes live.
  • Voicemail received — a caller leaves a voicemail. This rule is listed last and doesn’t show a friendly name on the Rules tab yet.
You can have more than one rule for the same event. That lets you notify one group one way and another group a different way — for instance, alert branch managers about every new lead while only looping in a regional lead for leads in their area.

​
Choose who gets notified

Each rule’s recipients are set using a targeting mode, chosen from the Who gets notified dropdown when you open a rule. The mode decides how the rule matches people:
1

By role

The simplest option. Pick one or more roles under Notify these roles, and everyone who holds one of those roles is notified. If the event belongs to a specific branch, the rule automatically keeps to people in that branch — so a branch-level event only reaches that branch’s team.
2

Specific people

Build a precise list of who should be included. You can combine roles, individual people, and branches, and choose whether someone needs to match any one of your criteria or all of them. Use this when “by role” is too broad and you want to hand-pick the audience.
3

Everyone except

Start broad and carve people out. You name the roles, people, or branches who should not be notified, and everyone else in the event’s branch is. Handy when almost the whole team should hear about something except one group.
In Specific people mode, the Recipient must match ALL of the above toggle is what flips the rule between “match any of these” and “match every one of these.” Leave it off for a wider audience; turn it on to narrow the rule to people who tick every box.

​
Limit a rule to certain triggers

Each rule can also list, under Only when triggered by, the roles that are allowed to trigger it. Only events started by someone holding one of those roles will fire the rule. Leave this empty and the rule fires no matter who — or what — set the event in motion, including events the system starts on its own (like the unpublished-event reminder). This is useful when the same event should notify people only in some situations. For example, you might want a “proposal signed” alert to go out only when the proposal belongs to a salesperson, and stay quiet otherwise.

​
Turn a rule on or off

Every rule has a single on/off switch. Turning a rule off stops it from sending notifications without removing it, so an alert can be paused during a quiet season — or while you’re fine-tuning who it reaches — and switched back on later. This is the quickest way to stop unwanted notifications without losing the rule’s setup; open the rule, flip the switch, and save.

​
How rules connect to branches and roles

Because rules target people by role and branch, they stay accurate only when those are set up correctly. If a rule isn’t reaching the right people, the usual cause is upstream: someone is missing a role, or a person isn’t assigned to the branch the event belongs to.

Manage people and access

Add team members and set the roles that notification rules target.

Set up branches

Define your branches so branch-scoped notifications reach the right local team.
If a notification didn’t go where you expected, check the rule’s targeting mode first, then confirm the intended recipients actually hold the role — and sit in the branch — the rule is looking for.