Managing User Notifications
How notifications are generated, who receives them, and how to configure them for each team member.
How Notifications Work
Something happens in Readybuild — a project is assigned, a comment is posted, a contract is signed — and the system works out who should hear about it, then checks each of those people's preferences before delivering anything.
Who Is Considered a Recipient
Recipients are determined by the event, not by a distribution list you maintain:
| Event type | Who is considered |
|---|---|
| Assignment (project user field, activity assignment) | The person assigned |
| Mention | The person @mentioned |
| Comment or note | Everyone following that project, contact, activity, or estimate line |
| Message | The participants of that message thread — internal messaging and client portal alike. Following is not involved. |
| Project Status (won, change order approved, contract signed) | Every active team member, then narrowed by each person's Scope setting |
| New Records and Form Submissions | Every active team member. New Records is skipped entirely during bulk data imports — the Import Wizard and vendor migrations create records silently. |
| Workflow notifications | Whoever the workflow's Send Notification action targets |
| Timesheets | Only the person whose timesheet was approved |
Two rules apply to all of them:
- You are never notified about your own action. Assigning a project to yourself, or commenting on something you follow, notifies everyone else and not you. Workflow notifications are the exception — no person triggered them.
- Deactivated users receive nothing. Only enabled team member accounts are considered, and system accounts are excluded from company-wide fan-outs.
How Delivery Is Decided
For each recipient, Readybuild reads that person's preference for that one notification type and delivers on two independent channels:
- RB Inbox — the notification appears in their Inbox and counts toward the unread badge
- Email — an email is sent to the address on their user account, from ReadyBuild Notifications <[email protected]>
Both, one, or neither can be on.
If RB Inbox is off and Email is set to Off for a type, nothing is created at all — no inbox entry, no email, no stored record. Turning the setting back on later does not bring back notifications that were skipped while it was off.
Defaults for New Team Members
Preferences are only stored once someone changes them. A new team member has no stored preferences and uses the defaults in the type table below — most types on for both channels, with New Records and Form Submissions off, and Project Status limited to followed projects.
You do not need to configure anything for a new hire to start receiving normal notifications.
Where Notification Settings Live
Notification preferences are per team member. There is no company-wide default and no permission-role switch — a permission role controls what someone can see and do, not what they are notified about. Changing settings for everyone in a role means opening each member of that role and setting them individually. See Setting Notifications by Permission Role for how to approach this in practice.
The Project Assignments type expands into a list of assignment roles — Sales Person, Project Manager, Estimator, and any other Team Member field on projects. Those are per-user switches over project fields, not permission roles, and they are set by each team member (or by you on their behalf) in the same panel as everything else.
Settings can be reached two ways:
- By the user themselves — either the gear icon in their Inbox, or their avatar menu → Notification Settings. See Notification Settings.
- By an administrator — Settings > My Company > Team Members → the ... menu on the person's row → Manage Notifications. This opens the Notifications tab on their record, which shows exactly what they see in their own settings.
Both routes edit the same preferences. A change you make as an administrator is not locked — the team member can change it back from their own inbox.
Configuring a Team Member's Notifications
- Go to Settings > My Company > Team Members
- Find the team member and click the ... menu on their row
- Select Manage Notifications
- Adjust the settings for each notification type
The panel lists one row per notification type with up to three settings:
| Setting | What it controls |
|---|---|
| RB Inbox | Whether notifications of this type appear in the user's inbox and unread count |
| Immediate sends an email as soon as the notification is created; Off sends none | |
| Scope | Only on types that support it (currently Project Status): All Projects notifies on every project, Followed Only limits it to projects the user follows. For change orders, Followed Only matches against the parent project. |
Each change saves immediately — there is no Save button, and no confirmation. Settings are applied one type at a time for one person at a time; there is no bulk or multi-user apply.
Notification Types and What Triggers Them
Each notification type can be configured independently for RB Inbox and email delivery. Use this table to work out why a notification arrived.
| Notification Type | What triggers it | Default |
|---|---|---|
| Mentions | Someone @mentions you in a project note, activity note, or comment. Being mentioned also starts you following that item. | RB Inbox on, email immediate |
| Comments | A new note or comment is added to a project, contact, activity, or estimate line you are following. If you were @mentioned in the same comment you receive the mention instead, not both. | RB Inbox on, email immediate |
| Project Assignments | You are set as the user on any Team Member field on a project — Sales Person, Project Manager, Estimator, Designer, Inside Sales, and any Team Member field your company has added. The message names the field. Expand this row to switch individual roles on or off — see below. | RB Inbox on, email immediate |
| Activity Assignments | You are set as the assigned user on an activity, or added to an activity's team. Also fires when either change arrives through a synced Outlook or Google calendar event. | RB Inbox on, email immediate |
| Messages | Someone sends you a message or replies in a message thread you are part of — a team member from internal messaging, or a client from the client portal. Recipients are the thread's participants; following is not involved. | RB Inbox on, email immediate |
| New Records | A project or a contact is created — entered by hand, arriving from a lead form, or created by an integration. Bulk data imports are excluded: the Import Wizard and vendor migrations create records without notifying anyone. | RB Inbox off, email off |
| Project Status | A project moves to a Won stage; a change order is approved; a contract is signed by a client; or a contract is canceled. Expand this row to control each of those separately — see below. | RB Inbox on, email immediate |
| Form Submissions | A public form is submitted — external lead forms, lead intake forms, contact forms, and online scheduling requests. | RB Inbox off, email off |
| Timesheets | Your timesheet is approved. Only the person whose timesheet it is receives this. | RB Inbox on, email immediate |
| Workflow Notifications | A workflow automation runs a Send Notification action. What triggers it and who receives it are set on the workflow itself — see Send Notification action. | RB Inbox on, email immediate |
Project Status also supports a Scope setting — choose All Projects to receive notifications for every project, or Followed Only to limit them to projects you are following. The default scope is Followed Only. For a change order, Followed Only matches against the parent project, so following the parent is enough to hear about its change orders.
Assignment roles
Project Assignments covers every Team Member field on a project, and each one is listed separately. Use the arrow beside it to expand the row and switch individual roles on or off:
| What is listed | Your company's own Team Member fields on projects, under your own labels — so the list reads "Project Developer" if that is what your company calls it, not "Sales Person" |
| Default | RB Inbox on, email on, for every role |
| What is not listed | Read-only fields such as Created By, and any field with Auto-subscribe on assignment turned off. Neither sends an assignment notification at all, so neither has a switch to offer |
Switch off the roles you are never assigned in, or the ones recorded for reporting rather than day-to-day work. The row's RB Inbox and Email settings remain the master switches for all of them.
Project Status events
Project Status covers several different moments. Use the arrow beside it to expand the row and switch each one on or off independently:
| Event | What triggers it | Default |
|---|---|---|
| Project won | A project proposal is fully signed by every client, or a project is moved to a Won stage by hand. | RB Inbox on, email on |
| Change order approved | A change order contract is fully signed, or a change order is moved to a Won stage. | RB Inbox on, email on |
| Contract partially signed | One client has signed but the contract is not yet fully executed. Most people only want to hear about the completed contract, so this one is off entirely until you turn it on. | RB Inbox off, email off |
| Contract canceled | A contract is canceled. | RB Inbox on, email on |
The row's own RB Inbox and Email settings are the master switches. An event can only narrow them — if you switch Project Status email off, no event under it sends email, and the event's own email switches grey out. The same is true of the roles under Project Assignments.
A row whose individual switches you have changed opens expanded the next time you visit the settings page, so nothing you turned off stays hidden behind a collapsed arrow.
Anyone listed as a company signee on a contract always receives the detailed contract email, regardless of these settings.
You never receive a notification for something you did yourself — assigning a project to yourself, or commenting on an item you follow, notifies everyone else but not you. The one exception is a notification sent by a workflow, which has no person behind it.
Troubleshooting
Not Receiving In-App Notifications
- Check your notification settings — Ensure the RB Inbox toggle is enabled for the notification type
- Check that you are following the entity — You only receive comment and update notifications for entities you follow
- Contact your administrator — They can verify your account settings
Not Receiving Email Notifications
- Check your email frequency setting — Ensure it is set to Immediate, not Off
- Check your email spam folder — Notification emails may be filtered
- Verify your email address — Ensure your profile has the correct email
Receiving Too Many Notifications
- Set Email Frequency to Off for notification types you only need in-app
- Unfollow entities you no longer need to follow
- Disable the RB Inbox toggle for notification types that are not relevant to your role
- Set Project Status scope to Followed Only so you hear about projects you follow rather than every project in the company
- Expand Project Status and switch off the individual events you do not need — for example turn off Change order approved if you only track new projects
Field-Level Configuration
Two settings on Team Member fields determine who can be assigned and what an assignment does. Both live in Settings > Form Fields on the field itself, not in notification settings.
Project Assignments Come from User Fields
Every Team Member field on a project generates a Project Assignments notification when someone is set in it — the built-in role fields such as Sales Person, Project Manager, Estimator, Inside Sales, and Drafter, plus any Team Member field your company has added. The notification names the field as it is labeled in your system, for example "You were assigned as Project Manager on Smith Kitchen Remodel."
This is automatic. Adding a new Team Member field to projects adds a new source of assignment notifications; there is no separate switch to turn one on.
Each user can, however, turn one off. Expanding the Project Assignments row in notification settings lists your company's assignment roles under your own field labels, each with its own RB Inbox and Email switch. A field that never notifies — a read-only field, or one with Auto-subscribe on assignment off — is not listed, because there would be nothing to switch.
Auto-subscribe on Assignment
Team Member fields on projects have an Auto-subscribe on assignment toggle, edited alongside the field in Settings > Form Fields. It is on by default for the built-in role fields and for new Team Member fields you create.
| Toggle | What the assigned user gets |
|---|---|
| On | The assignment notification, and they start following the project — so they also receive comments, notes, and status changes on it from then on |
| Off | Nothing. No assignment notification, and no automatic follow. The field records the assignment silently. |
Turn it off for fields where an assignment does not need announcing — a reference field such as "Referred By," or a role recorded for reporting rather than day-to-day work. Users can still follow the project manually at any time.
Off suppresses the Project Assignments notification for that field as well as the automatic follow, for every user, and the field does not appear in anyone's per-role list in notification settings. There is no setting that notifies the assignee without also subscribing them: to notify without forcing the subscription, leave the toggle on and have each user switch that role off in their own settings.
Turning Auto-subscribe on assignment off does not unfollow anyone who is already following that project. It only changes what happens on future assignments.
Restricting a Field to Certain Roles
Team Member fields have a Roles setting that filters which users appear in the dropdown (blank means all users). Because assignment notifications follow the field, this indirectly controls which roles ever receive Project Assignments for that field — restricting a "Lead Carpenter" field to the Lead Carpenter role means nobody outside that role can be assigned, and so nobody outside it gets that notification.
Use this to keep assignment lists clean. Do not use it as a notification control — someone in an allowed role who has Project Assignments turned off still won't be notified.
See Form Fields for full field configuration.
Setting Notifications by Permission Role
Readybuild has no permission-role notification setting, so role-based configuration is a convention you apply when onboarding rather than something the system enforces. The practical approach is to decide a baseline per role, then apply it as each person is set up.
Recommended Baseline by Role
Each row lists every type that should be on for that role. Anything not listed can be turned off.
| Role | Notification types to enable |
|---|---|
| Sales | Mentions, Comments, Project Assignments, Activity Assignments, Project Status, New Records, Timesheets |
| Project Manager | Mentions, Comments, Project Assignments, Activity Assignments, Project Status, Timesheets |
| Estimating | Mentions, Comments, Project Assignments, Project Status, Timesheets |
| Design | Mentions, Comments, Project Assignments, Activity Assignments, Project Status, Timesheets |
| Field Staff / Lead Carpenter | Mentions, Comments, Activity Assignments, Timesheets |
| Marketing | Mentions, Comments, New Records, Form Submissions, Timesheets |
| Accounting | Mentions, Comments, Project Status, Timesheets |
| Admin | All types |
These are starting points, not requirements. Three things are worth understanding before you deviate:
- Mentions and Comments should stay on for anyone expected to take part in project discussion — turning them off means a direct @mention goes nowhere.
- Project Status belongs on for anyone whose work starts when a project is won or a contract is signed, which includes design as well as sales and production.
- Timesheets only ever reaches the person whose own timesheet was approved, so it costs nothing to leave on for anyone who submits time.
Because most types are on by default, following this table usually means turning a few types off rather than on — the exception is New Records and Form Submissions, which start off and need enabling for the roles that triage incoming leads.
Onboarding a New Team Member
- Confirm their user account has a valid email address — email notifications go to that address and nowhere else
- Leave the defaults alone unless their role needs something different; the defaults are already sensible for most users
- Turn on New Records or Form Submissions only for people who genuinely triage incoming leads — these fire for every new record in the company
- Set Project Status scope to All Projects for managers who track the whole pipeline; leave it on Followed Only for everyone else
- Tell them they can adjust their own settings from the inbox gear icon
Auditing
Notification settings drift as people change roles. Periodically check that:
- Key personnel still have Mentions and Comments enabled
- Nobody who left a triage role still has company-wide New Records or Form Submissions turned on
- People who moved into management have Project Status scoped the way they need it
- Team members who complain about email volume have been shown the Email → Off option rather than turning off RB Inbox, which loses the record entirely
Workflow-Driven Notifications
Notifications sent by the Send Notification workflow action arrive as the Workflow Notifications type, so a user who turns that type off will not receive them — including workflow alerts you consider mandatory.
When delivery must be guaranteed regardless of preferences, use the Send Internal Email action instead. See Send Notification for the comparison.
Troubleshooting
A Team Member Says They Are Not Getting Notifications
Work through these in order:
- Check the type, not notifications as a whole — open their Notifications tab and confirm the specific type is on for the channel they expect
- Check the scope — for Project Status, Followed Only means they only hear about projects they follow
- Check whether they follow the item — Comments and Messages only reach followers. Their assignment may have come through a field with Auto-subscribe on assignment turned off, which neither notifies nor subscribes
- Check the role, not just the type — expand Project Assignments in their settings; they may have switched off the specific role they were assigned in
- Check their email address — email goes to the address on their user account; a typo or a shared mailbox will silently swallow it
- Check their spam filter — notification emails come from
[email protected]. Have IT allow that address - Confirm they were not the actor — nobody is notified about their own action
A Team Member Is Getting Too Many
- Set Email to Off for types they only need in the inbox — the notification is still recorded, just not emailed
- Set Project Status scope to Followed Only
- Turn off New Records and Form Submissions unless they triage leads
- Have them unfollow projects they no longer work on, rather than turning off Comments entirely