V2 Notifications System Overhaul

V1 Notification Settings is a flat, company-level toggle list (New Appointment, Proposal Accepted, Proposal Rejected, Proposal Viewed, Invoice Viewed, Invoice Sent, Chat Message Received) with no channel selection, no per-user preferences, no in-app notification center, and no delivery history.

Enhancement Ticket — V2 Notifications System Overhaul

Ticket Type: Enhancement Target Version: V2 Status: Placeholder — Pending Discovery & Scoping Priority: TBD Area: Notifications / Settings / User Experience

Summary

The current V1 notifications system is a flat list of on/off toggles scoped to the company account level. It provides no delivery channel selection, no per-user preference control, no in-app notification inbox, and no notification history. This ticket captures the full scope of known V1 gaps, FeatureBase user requests, and PM roadmap items that should be addressed in the V2 notifications overhaul. This is a placeholder intended to anchor discovery, scope definition, and design decisions before active development begins.

User Story

As a DripJobs user (owner, admin, or team member), I want a notifications system that gives me meaningful, timely, and personalized alerts about the events that matter to my role, delivered through the channels I prefer, so that I never miss a critical business moment and am not overwhelmed by irrelevant noise.

Business Rules (Functional Requirements)

1. Notification Categories & Event Coverage

The V2 system must support notifications across all major workflow areas. At minimum, the following event categories must be represented:

Proposals & Estimates

• Proposal sent to customer

• Proposal viewed by customer

• Proposal accepted

• Proposal rejected / declined

• Proposal expired (if expiration logic exists in V2)

• Counter-signature completed

Appointments & Scheduling

• New appointment created

• Appointment confirmed by customer

• Appointment rescheduled

• Appointment cancelled

• Appointment reminder (pre-appointment)

Jobs & Work Orders

• Job created from accepted proposal

• Work order sent

• Work order viewed

• Job status changed

• Job marked complete

Invoices & Payments

• Invoice sent to customer

• Invoice viewed by customer

• Invoice paid

• Invoice overdue (if applicable)

• Deposit received

• Payment failed or declined

Communications

• New chat message received (DJ Chat / in-app messaging)

• New inbound SMS received (if Text Messaging add-on is active)

• New inbound email reply received

Leads & Pipeline

• New lead created (manual or via integration)

• Lead assigned to a team member

• Deal stage changed

• Deal archived or lost

Team & Internal

• Task assigned to a user

• Task completed

• Mention or tag (if V2 introduces @mentions)

• New team member added to account

Automations (Drips)

• Drip sequence enrolled

• Drip step failed to send

• Drip sequence completed

2. Delivery Channels

The system must support multiple notification delivery channels. Each notification event must be configurable per channel independently:

• In-App (Notification Center) — persistent, visible within the DripJobs app

• Email — sent to the user's account email address

• Push Notification — mobile push via iOS and Android apps

• SMS — optional channel; must only be available if the account has the Text Messaging add-on active

3. Notification Preferences — User-Level Control

Each individual user on an account must be able to configure their own notification preferences independently. Company-wide defaults may exist, but individual users must be able to override them for their own account.

Preference controls must allow a user to:

• Enable or disable a notification event entirely

• Select which delivery channels they want for each event (e.g., in-app only, email + push, etc.)

• Set quiet hours during which push and SMS notifications are suppressed

Account owners and admins must be able to:

• Set company-wide default notification preferences that apply to new users on the account

• View which users have notifications enabled for critical events (e.g., invoice paid)

• Optionally enforce certain notification types so individual users cannot disable them (e.g., payment received)

4. In-App Notification Center

V2 must include a persistent in-app notification center (notification inbox/bell) that:

• Displays a real-time count of unread notifications

• Shows a chronological feed of all in-app notifications

• Allows users to mark individual notifications as read or mark all as read

• Allows users to dismiss or clear notifications

• Provides a direct link from each notification to the relevant record (proposal, job, invoice, deal, etc.)

• Persists notification history for a defined lookback window (open question — see below)

• Distinguishes between read and unread states visually

5. Notification Content & Formatting

Each notification must include sufficient context for the user to understand and act without needing to navigate elsewhere first. At minimum, each notification must include:

• The event type (e.g., "Proposal Accepted")

• The customer name and/or company name

• The relevant record name or identifier (e.g., proposal title, job name, invoice number)

• A timestamp

• A direct action link to the affected record

Notifications must not expose sensitive financial data (e.g., full payment amounts in push/SMS) beyond what is appropriate for the channel.

6. Role-Based Notification Relevance

Notification events should be scoped to the user's role where applicable. A field technician should not receive notifications about invoice payment events unless their role warrants it. An admin or owner should receive account-level alerts that a standard user would not. The system must support role-aware defaults while still allowing individual user overrides.

7. Notification Grouping & Digest (Future Consideration)

For users who receive high notification volume, the system should support notification grouping or a digest option. For example:

• Group multiple "Proposal Viewed" events from the same customer into a single notification rather than firing individually

• Provide a daily or weekly summary digest option via email for users who prefer reduced real-time noise

Note: This may be scoped to a follow-on enhancement if it introduces significant complexity.

8. Integration Event Notifications

When activity originates from an integration (Zapier, QuickBooks, CompanyCam, etc.), the notification system must accurately attribute the event source and still route the notification through the standard preferences system. Integration-triggered events must not bypass user notification settings.

Edge Cases & Exceptions

• If a user has the Text Messaging add-on disabled, SMS must not appear as an available delivery channel in their notification preferences.

• If quiet hours are enabled and an event fires during that window, the notification must be held until quiet hours end (or delivered in-app only, depending on channel). The expected behavior for this scenario must be defined during discovery.

• If a user is deleted or deactivated from an account, their notification preferences must be archived and no further notifications delivered.

• Notifications triggered by the user's own actions (e.g., a user sending a proposal to themselves for testing) should be suppressed or clearly flagged as self-triggered to avoid confusion.

• If a notification deep-link points to a record that has since been deleted or archived, the system must handle gracefully without producing an error state.

• Accounts without the Text Messaging add-on must not see SMS as a notification channel option anywhere in the UI.

• Mobile push notifications must respect the device-level notification permissions granted by the user in iOS/Android system settings. If permissions are denied at the OS level, the system must surface guidance prompting the user to enable them.

Acceptance Criteria

• [ ] All V1 notification events are preserved and available in V2 with no regression in coverage

• [ ] Each notification event supports independent per-channel configuration (in-app, email, push, SMS where applicable)

• [ ] Individual users can configure their own notification preferences without affecting other users on the same account

• [ ] Account owners and admins can set and manage company-wide default preferences

• [ ] An in-app notification center is accessible from all pages in the application and displays real-time unread counts

• [ ] Each in-app notification links directly to the relevant record

• [ ] Notification history is retained and browsable within the notification center

• [ ] Read/unread states are tracked and reflected accurately

• [ ] Users with the Text Messaging add-on inactive cannot select SMS as a notification delivery channel

• [ ] Quiet hours suppress push and SMS notifications during the defined window

• [ ] Role-based default preferences are applied to new users at account creation

• [ ] All notification preference changes take effect immediately without requiring a page reload or re-login

• [ ] Notifications originating from integrations route through the same preference system as manually triggered notifications

Open Questions for Discovery

The following questions must be resolved before this ticket moves to active development:

1. Notification history retention window — How long should in-app notifications be retained? 30 days? 90 days? Indefinitely with a manual clear option?

2. Enforcement vs. preference — Which notification types (if any) should account owners be able to enforce so users cannot disable them?

3. Digest / grouping scope — Is notification grouping or digest mode in V2 scope or a follow-on?

4. Quiet hours behavior — When quiet hours suppress a push/SMS notification, should it be delivered after quiet hours end, discarded, or delivered in-app only?

5. Real-time delivery mechanism — This is an architecture decision for the dev team, but PM needs to confirm whether real-time in-app notifications (e.g., bell count updates without page refresh) are in V2 scope.

6. Customer-facing notifications — Should customers receive any notifications through the DripJobs system (e.g., proposal ready, appointment reminder), or is this separate from the internal user notification system? This may overlap with the existing drip/automation and customer portal scope.

7. Mention / @tag system — Is this a V2 feature? If so, notification support for mentions must be coordinated with that ticket.

8. Multi-location / multi-account — If V2 supports multiple locations under a single user login, how do notification preferences map across locations?

Dependencies & Related Areas

• V2 User Roles & Permissions system (role-based defaults depend on this)

• V2 Text Messaging / SMS add-on architecture

• V2 Mobile app (push notification infrastructure)

• V2 Plan Tier architecture (certain notification features may be plan-gated)

• Customer Portal / Customer-Facing communications (scope boundary must be defined)

• Drips / Automation system (integration event notifications)

Notes

This ticket is a placeholder and discovery anchor, not a finalized spec. Scope, priority, and phasing decisions should be made jointly by PM, CTO, and CEO before this moves to development. Individual sub-features identified here may warrant their own child tickets once scoping is complete.