Settings → Project Stages → Notifications lists every stage with the rule currently IN EFFECT for it and where that rule came from. Rules can be set at three levels: this stage in this template, this KIND of stage in any template, or every stage. Recipients and channels (in-app, email, SMS) are chosen per rule, along with optional per-stage wording.
Also called: stage notifications · who gets emailed · notify the customer on this stage only · too many notifications
Tell the customer when framing finishes on a barndominium, but not on a shed
Every building type's framing stage used to share one identity, so that sentence could not be said: builders took the customer emails on everything or on nothing, and the ones who found them noisy switched the lot off. Rules attach to a specific stage on a specific building type. Recipients and channels are chosen per rule — the owner, the project manager, the assigned crew's lead, named people, the customer — over in-app, email or text.
Set it for one stage, for that kind of stage everywhere, or for everything
Three levels, most specific first, and every stage shows the rule actually in effect on it and where that rule was inherited from. The settings screen works out the winner using the same logic that sends the mail. Two versions of that is how a settings screen ends up confidently describing behaviour the system does not have.
Untick the customer on one stage and the customer stops getting that stage
The winning rule applies as a whole row rather than merging field by field with the broader ones. Merge them and a builder who opens one stage and unticks "customer" still emails the customer, because something wider said so — and the setting he just changed appears to do nothing. Deleting a rule means inherit again; silence is a rule somebody chose, not the absence of one.
Renaming a stage does not silently switch its emails off
Rules bind to the stage's own durable identity, not to the words on it, so tidying "Framing" to "Post Set" keeps everything hanging off it. Before that, a builder saw a better name, lost the notifications behind it, and found out weeks later when a customer said nobody had told him anything.
Your own wording per stage, still inside your own branding
Per-stage wording drops in with the stage, the project and the person filled in, and it rides inside the builder's branded email rather than replacing it. Configuring a rule used to swap the customer's email from the builder's own colours to a hardcoded block in somebody else's — setting up the automation made the result worse than leaving it alone.
- 1Routing binds to stage_definitions.id, not the slug — 'rename the stage and the rule stops matching, delete it and the rule lingers forever'
- 2Resolution reads all three rungs in ONE query and ranks them in memory, most specific first
- 3The winning rule applies as a WHOLE ROW, deliberately not a field-merge: 'a builder who opens one stage and unticks "customer" would still email the customer because a broader row said so — the setting they just changed appears to do nothing'
- 4'No rule at all' returns null and the legacy org-wide behaviour continues; silence is a rule with enabled=false, which a builder has to choose
- 5Deleting a rule means 'inherit again', which is different from disabling
- 6Per-stage copy overrides ({stage}, {project}, {who} tokens) ride INSIDE the tenant-branded shell
Every building type's framing stage shared a single identity, so 'email the customer when framing finishes on barndominiums but not on sheds' was unsayable — builders took the emails everywhere or nowhere, and the ones who found them noisy turned the whole thing off. Rules attach to a specific stage on a specific building type. The settings screen answers 'which rule wins' using the same logic that actually sends the mail, because two versions of that is how a settings screen ends up confidently describing behaviour the system does not have. Configuring a rule also used to swap the customer's email from the builder's own branding to a hardcoded block in someone else's colours — setting up an automation made the result worse.
- All-or-nothing notification settings
- Renaming a stage orphaning its rules
- Settings screens describing behaviour the system doesn't have
- Configuring an automation degrading the customer's email
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →