← 30. Notifications
Chunks — 30. Notifications
The FRD markdown is the source of truth; these chunks are the derived retrieval index used to give the test-case generator only the relevant slices. Rebuilt automatically when the FRD is saved.
187 chunks · ~33,753 tokens
#1
(intro)
~4 tok
☑️ Notifications
#2
(intro)
~1 tok
#
#3
(intro)
~1 tok
#
#4
(intro)
~1 tok
#
#5
(intro)
~1 tok
#
#6
(intro)
~1 tok
#
#7
**Notifications**
~46 tok
# **Notifications** **Functional Requirement Document** **BA & Ideation: Deval Chauhan** **Reviewed By: Keval Gajjar** **Updated Date:10 December 2025 Status:** **Version: 1.0**
#8
**Notifications** > **Overview**
~76 tok
## **Overview** The Notifications module delivers personalized, role-based alerts to users across Pixally CRM. It consists of three sub-modules: **Notification Center** (viewing interface), **Company Notifications** (organization-wide defaults), and **Personal Notifications** (individual preferences).
#9
**Notifications** > **1\. Notification Center**
~225 tok
## **1\. Notification Center** **Purpose:** Centralized hub for viewing and interacting with all notifications via the bell icon. **Feature** **Description** **Bell Icon &Badge** Visible on all screens (top-right); badge shows unread count (max "99+") **Tabs** "All" (default) and "Unread" with count badge **Mark as Read** Click the notification or the "Mark all as read" link **Pagination** "Load More" button; notifications retained indefinitely **Categories** Projects & Events, Messaging, News & Updates, System **Inline CTAs** Pay Now, Decline, Reply, Download, Send Reminder, Update Payment Method **Deep Linking** Click notification → navigate to relevant module/record **Multi-Agency** Contractors see unified notifications across all agencies; auto-context switch on click **Access:** All authenticated users | **Notifications ordered by:** Date received (newest first)
#10
**Notifications** > **2\. Company Notifications**
~226 tok
## **2\. Company Notifications** **Purpose:** Organization-wide notification defaults configured by Agency Owner/Admin. **Setting Category** **Notification Types** **Channels** **Payment Reminders** Upcoming (7 days), Due date, Overdue +2 days, Overdue +5 days None, SMS, Email **Contractor Reminders** 2 days before event, 7 days before event None, SMS, Email **Snapshot** PDF with project details sent 1 day before event Off / On **Internal Team** Event reminder (1 week), Lead response alert, Task due, Task completed None, In-App, Email **Key Rules:** * **Access:** Agency Owner and Admin only * **Override Behavior:** Sets defaults; does NOT lock personal customization * **Multi-Admin:** Last save wins (no locking) * **Lead Response Alert:** Configurable threshold (3, 5, 7, 10, 14 days) * **Subscription Gating:** Contractor features require Contractor Portal add-on
#11
**Notifications** > **3\. Personal Notifications**
~24 tok
## **3\. Personal Notifications** **Purpose:** Individual notification preferences by user role.
#12
**Notifications** > **3\. Personal Notifications** > Role-Based Notification Categories
~156 tok
### Role-Based Notification Categories **Role** **Categories Available** **Normal Subscriber** (Owner, Admin, PM, Staff) Finance & Invoicing (6), Projects & Events (14), Client & Contractor Activity (6), Post-Production (6), News (1) **Editor** Assignments & Tasks (5), Feedback & Collaboration (4), Payments (1) **Contractor** Project Assignment (6), Deliverables & Tasks (4), Communication (3), Payments (5), Forms & Contracts (5), Security (4) **Client** ❌ No settings access — receives all notifications automatically **Gawd Portal** User Activity (2), Payments & Billing (4), Account Status (3), Security (2)
#13
**Notifications** > **3\. Personal Notifications** > Channel Options
~60 tok
### Channel Options **Option** **Behavior** **None** Notification disabled **In-App** Appears in Notification Center **Email** Sent to registered email **Multi-select allowed:** Users can enable both In-App AND Email simultaneously.
#14
**Notifications** > **3\. Personal Notifications** > Default & Override Logic
~76 tok
### Default & Override Logic Priority: Personal Setting > Company Setting > System Default * **New Users:** All notifications ON (In-App + Email) by default * **Customization:** Personal changes override company defaults * **Company Changes:** Only affect users who haven't customized that setting
#15
**Notifications** > **User Access Matrix**
~66 tok
## **User Access Matrix** **Role** **Notification Center** **Personal Settings** **Company Settings** Agency Owner ✅ ✅ ✅ Admin ✅ ✅ ✅ Project Manager ✅ ✅ ❌ Staff ✅ ✅ ❌ Editor ✅ ✅ ❌ Contractor ✅ ✅ ❌ Client ✅ ❌ ❌ Gawd Portal ✅ ✅ ❌
#16
**Notifications** > **Key Business Rules**
~165 tok
## **Key Business Rules** **Rule** **Description** **Default ON** All notifications enabled (In-App + Email) for new users across all roles **Lifetime Retention** Notifications stored indefinitely; newest first **Auto-Save** All setting changes auto-save without explicit save button **Subscription Gating** Post-Production, Contractor Portal features gated by subscription **Multi-Agency Contractors** Unified notification view; click switches agency context automatically **Client Notifications** Non-configurable; follow company payment reminder settings **Deleted Entities** Clicking notification shows "This record no longer exists" error
#17
**Notifications** > **Additional Notifications (from Client MOM)**
~148 tok
## **Additional Notifications (from Client MOM)** **Notification** **Target Role** **Trigger** W9 Annual Reminder Contractor Every January $600 Payment Threshold Contractor Cumulative payments exceed IRS threshold IC Agreement Reminder Contractor Weekly if unsigned Lead Conflict Warning Normal Subscriber New lead conflicts with existing booking Unassigned Contractor Alert Normal Subscriber Project booked without contractor Weekly Summary - Overdue Jobs Normal Subscriber Digest of jobs needing assignment Account Suspended Warning All Users Agency payment failure
#18
**Notifications** > **Dependencies**
~88 tok
## **Dependencies** **Type** **Key Dependencies** **Internal Modules** Projects, Finance, Contracts, Post-Production, Leads, Tasks, User Management, Subscription **External Services** Email (SendGrid/SES), SMS (Twilio), PDF Generation **Infrastructure** Database, Background Job Processor, WebSocket/Real-time Service ☑️ 1. Notification Center
#19
**FRD: Notification Center**
~8 tok
# **FRD: Notification Center**
#20
**FRD: Notification Center** > Product: Pixally CRM | Version: 1.0 | Date: December 11, 2025 | Related FRDs: Company Notifications, Personal Notifications
~32 tok
### Product: Pixally CRM | Version: 1.0 | Date: December 11, 2025 | Related FRDs: Company Notifications, Personal Notifications
#21
**FRD: Notification Center** >
~1 tok
###
#22
**FRD: Notification Center** > **1\. Module Overview**
~7 tok
## **1\. Module Overview**
#23
**FRD: Notification Center** > **1\. Module Overview** > 1.1 Module Name
~10 tok
### 1.1 Module Name Notification Center
#24
**FRD: Notification Center** > **1\. Module Overview** > 1.2 Purpose
~139 tok
### 1.2 Purpose The Notification Center serves as the centralized hub for viewing and interacting with all notifications within Pixally CRM. Accessible via the bell icon positioned in the top-right corner of the application header, it provides users with a unified interface to view, filter, and act upon personalized alerts about important activities occurring throughout the platform. The module supports real-time notification delivery, deep linking to source modules, inline action buttons, and multi-agency notification aggregation for contractors.
#25
**FRD: Notification Center** > **1\. Module Overview** > 1.3 Business Goals
~237 tok
### 1.3 Business Goals * Provide a single, always-accessible location for users to view all their notifications from any screen within the application. * Keep users informed of important activities in real-time through immediate notification delivery and dynamic badge updates on the bell icon. * Enable users to quickly navigate to relevant modules and specific records through deep linking when clicking on notifications. * Allow users to take immediate actions such as signing contracts, processing payments, replying to messages, and downloading files directly from the notification panel without navigating away. * Support efficient notification management through filtering capabilities using All and Unread tabs, mark-as-read functionality, and Load More pagination. * Provide contractors working with multiple agencies a unified view of all notifications with seamless context switching when clicking cross-agency notifications.
#26
**FRD: Notification Center** > **2\. User Roles & Permissions**
~9 tok
## **2\. User Roles & Permissions**
#27
**FRD: Notification Center** > **2\. User Roles & Permissions** > 2.1 Roles with Access to Notification Center
~140 tok
### 2.1 Roles with Access to Notification Center **Role** **Access Notification Center** **View All Notifications** **View Unread Only** **Mark as Read** **Perform Inline Actions** **Navigate via Deep Link** Agency Owner Yes Yes Yes Yes Yes Yes Admin Yes Yes Yes Yes Yes Yes Project Manager Yes Yes Yes Yes Yes Yes Normal User (Staff) Yes Yes Yes Yes Yes Yes Editor Yes Yes Yes Yes Yes Yes Contractor Yes Yes Yes Yes Yes Yes Client Yes Yes Yes Yes Yes Yes Gawd Portal User Yes Yes Yes Yes Yes Yes
#28
**FRD: Notification Center** > **2\. User Roles & Permissions** > 2.2 Notification Visibility Scope by Role
~217 tok
### 2.2 Notification Visibility Scope by Role **Role** **Notification Scope** Agency Owner Receives notifications for all projects and activities across the entire company Admin Receives notifications for all projects and activities across the entire company Project Manager Receives notifications only for projects they are directly associated with Normal User (Staff) Receives notifications only for projects they are directly associated with Editor Receives notifications only for post-production boards and tasks they are assigned to Contractor Receives notifications for assigned tasks and projects across ALL agencies they work with in a unified view Client Receives notifications only for their own project-related activities Gawd Portal User Receives platform-wide administrative notifications related to subscriptions, billing, and security
#29
**FRD: Notification Center** > **2\. User Roles & Permissions** > 2.3 Permission Details
~144 tok
### 2.3 Permission Details * All authenticated users can access the Notification Center by clicking the bell icon visible on all screens. * Users can only view notifications targeted to them based on their role and project associations. * Deep link navigation is subject to the user's existing permissions in the target module. * Inline action execution is subject to the user's permissions for the specific action being performed. * Contractors can view and interact with notifications from all agencies they are associated with without manual context switching.
#30
**FRD: Notification Center** > **3\. User Flow**
~800 tok
## **3\. User Flow** 3.1 The user logs into Pixally CRM and lands on any screen within the application. 3.2 The system displays the bell icon in the top-right corner of the header navigation bar on all screens. 3.3 The system displays a numeric badge on the bell icon showing the count of unread notifications, or hides the badge if the count is zero. 3.4 The user clicks on the bell icon to open the Notification Center. 3.5 The system opens the Notification Center as a dropdown panel overlay with a subtle background gradient effect applied to the underlying page. 3.6 The system displays the panel header containing the title "Notifications", a "Mark all as read" link with checkmark icon, and a settings gear icon. 3.7 The system displays two segment tabs below the header labeled "All" and "Unread", with the "All" tab selected by default. 3.8 The system displays the "Unread" tab with a badge showing the count of unread notifications. 3.9 The system loads and displays the notification list below the tabs, sorted by creation timestamp with the newest notifications appearing first. 3.10 The system displays each notification item with a category icon, title message, relative timestamp, context information showing the related project name, and a read/unread visual indicator. 3.11 The user scrolls through the notification list to view older notifications. 3.12 The user clicks on the "Unread" tab to filter the list. 3.13 The system immediately updates the notification list to display only unread notifications. 3.14 The user clicks on the "All" tab to return to the full list. 3.15 The system immediately updates the notification list to display all notifications regardless of read status. 3.16 The user clicks on a notification item that does not have inline action buttons. 3.17 The system marks the clicked notification as read and updates the unread count badge on the bell icon. 3.18 The system closes the Notification Center panel and navigates the user to the relevant module and specific record via deep linking. 3.19 The user returns to a screen and opens the Notification Center again. 3.20 The user identifies a notification with inline action buttons such as "Pay Now" and "Decline". 3.21 The user clicks on the "Pay Now" button within the notification. 3.22 The system opens the payment flow modal or navigates to the payment page without marking the notification as read. 3.23 The user completes the payment action. 3.24 The system updates the notification state to reflect the completed action and removes or disables the action buttons. 3.25 The user clicks on "Mark all as read" link in the panel header. 3.26 The system marks all notifications as read, updates the bell icon badge to show zero or hides it, and updates the Unread tab badge to zero. 3.27 The user scrolls to the bottom of the notification list and sees the "Load More" button. 3.28 The user clicks on "Load More" to fetch additional notifications. 3.29 The system displays a loading indicator while fetching the next batch of notifications. 3.30 The system appends the newly loaded notifications to the bottom of the existing list and maintains the user's scroll position.
#31
**FRD: Notification Center** > **3\. User Flow**
~213 tok
3.31 The system hides the "Load More" button when all notifications have been loaded. 3.32 The user clicks outside the Notification Center panel. 3.33 The system closes the Notification Center panel. 3.34 A contractor user who works with multiple agencies opens the Notification Center. 3.35 The system displays notifications from all associated agencies in a unified list, with each notification showing the agency brand identifier. 3.36 The contractor clicks on a notification from a different agency than the currently active one. 3.37 The system automatically switches the contractor's active agency context to the notification's agency. 3.38 The system navigates the contractor to the deep link target within the newly switched agency context. 3.39 The system displays a brief toast notification indicating "Switched to \[Agency Name\]".
#32
**FRD: Notification Center** > **4\. Functional Logic**
~7 tok
## **4\. Functional Logic**
#33
**FRD: Notification Center** > **4\. Functional Logic** > 4.1 Bell Icon and Badge Behavior
~327 tok
### 4.1 Bell Icon and Badge Behavior * The bell icon shall be rendered in the top-right corner of the application header and shall remain visible on all authenticated screens regardless of the module the user is viewing. * The bell icon shall display a numeric badge positioned at its top-right corner that shows the total count of unread notifications for the logged-in user. * When the unread notification count is between 1 and 99, the badge shall display the exact numeric count. * When the unread notification count exceeds 99, the badge shall display "99+" to maintain visual consistency and prevent layout overflow issues. * When the unread notification count is zero, the system shall hide the badge completely and display only the bell icon without any numeric indicator. * The badge count shall update in real-time or near real-time whenever a new notification is received or when notifications are marked as read. * Clicking the bell icon shall toggle the Notification Center panel between open and closed states. * The bell icon shall display a hover state with visual feedback to indicate interactivity when the user moves the cursor over it. * The bell icon shall display an active or selected state with distinct styling when the Notification Center panel is currently open.
#34
**FRD: Notification Center** > **4\. Functional Logic** > 4.2 Notification Panel Layout and Display
~298 tok
### 4.2 Notification Panel Layout and Display * The Notification Center shall open as a dropdown panel overlay anchored to the bell icon and positioned below or adjacent to it. * The panel shall have a fixed width of approximately 380-420 pixels and a maximum height with internal vertical scrolling enabled for the notification list. * When the panel opens, a subtle background overlay with gradient effect shall be applied to the underlying page content to draw visual focus to the notification panel. * The panel header shall display the title "Notifications" aligned to the left side of the header area. * The panel header shall display a "Mark all as read" action link with a checkmark icon aligned to the right side of the header. * The panel header shall display a settings gear icon next to the "Mark all as read" link that navigates users to the Notification Settings page when clicked. * Clicking anywhere outside the panel boundaries shall close the Notification Center panel. * Clicking the bell icon while the panel is open shall close the panel. * The panel shall automatically close when the user navigates away from the current page via a deep link click.
#35
**FRD: Notification Center** > **4\. Functional Logic** > 4.3 Tab Filtering Functionality
~260 tok
### 4.3 Tab Filtering Functionality * The Notification Center shall display two segment tabs labeled "All" and "Unread" positioned below the panel header. * The "All" tab shall be selected by default when the Notification Center panel opens. * When the "All" tab is selected, the system shall display all notifications regardless of their read or unread status, sorted by creation timestamp with newest first. * The "Unread" tab shall display a badge showing the current count of unread notifications. * When the "Unread" tab is selected, the system shall filter and display only notifications where the read status is false, sorted by creation timestamp with newest first. * Switching between tabs shall immediately update the displayed notification list without requiring a full page reload. * When the user marks all notifications as read while viewing the Unread tab, the system shall update the list to display an empty state message. * Tab switching shall reset the scroll position to the top of the notification list.
#36
**FRD: Notification Center** > **4\. Functional Logic** > 4.4 Notification Item Structure and Display
~364 tok
### 4.4 Notification Item Structure and Display * Each notification item in the list shall display a category-specific icon on the left side that visually represents the notification type such as a document icon for questionnaires, a dollar icon for payments, or a calendar icon for events. * Each notification item shall display a read/unread indicator that visually distinguishes unread notifications through bold text styling, a colored dot, or background highlighting. * Each notification item shall display the primary title or message text describing the event that triggered the notification, formatted with the actor's name in bold. * Each notification item shall display a relative timestamp indicating how long ago the notification was created using formats such as "Just now", "X minutes ago", "X hours ago", "Yesterday", "X days ago", or the date in "MMM DD" format for older notifications. * Each notification item shall display context information in a secondary muted text style showing the related project or event name such as "Jadon & Monika Wedding". * For notifications related to agencies in a multi-agency contractor scenario, each notification shall display the agency brand identifier to help contractors distinguish the source. * Long notification titles or context information that exceeds the available display width shall be truncated with an ellipsis, and the full text shall be displayed in a tooltip on hover.
#37
**FRD: Notification Center** > **4\. Functional Logic** > 4.5 Notification Categories and Types
~10 tok
### 4.5 Notification Categories and Types
#38
**FRD: Notification Center** > **4\. Functional Logic** > 4.5 Notification Categories and Types > **4.5.1 Projects and Events Category**
~681 tok
#### **4.5.1 Projects and Events Category** * When a client completes and submits a questionnaire, the system shall trigger the "Questionnaire was filled out" notification and deliver it to the Agency Owner, Admin, and Project Manager associated with that project via their configured notification channels. * When a prospective client submits a lead form, the system shall trigger the "Lead form was submitted" notification and deliver it to the Agency Owner and Admin, as well as the designated lead handler if one is assigned. * When a client opens and views a sent proposal, the system shall trigger the "Proposal was viewed" notification and deliver it to the Agency Owner, Admin, and the user who sent the proposal. * When a client completes full payment on an invoice, the system shall trigger the "Invoice was paid" notification and deliver it to the Agency Owner, Admin, and Project Manager associated with that project. * When a booking proposal reaches its expiration date without being signed, the system shall trigger the "Booking proposal expires" notification and deliver it to the Agency Owner, Admin, and Project Manager as a warning indicator. * When a client signs a contract, the system shall trigger the "Contract was signed" notification and deliver it to the Agency Owner, Admin, and Project Manager associated with that project. * When a user uploads a file to a project, the system shall trigger the "File uploaded" notification and deliver it to all team members associated with that project. * When an event date is 5 days away, the system shall trigger the "Upcoming event reminder" notification and deliver it to the Agency Owner, Admin, Project Manager, and assigned contractors for that event. * When a new email is received in the Pixally email system for a project, the system shall trigger the "New email received" notification and deliver it to the project owner and associated team members. * When a task passes its due date without being completed, the system shall trigger the "Overdue tasks" notification and deliver it to the task assignee and the user who created the task. * When a task deadline is approaching based on configured reminder settings, the system shall trigger the "Task reminders" notification and deliver it to the task assignee. * When there is activity in the referral program such as a new referral or conversion, the system shall trigger the "Referral program updates" notification and deliver it to the Agency Owner and Admin. * When a project or event is canceled, the system shall trigger the "Project/Event canceled" notification and deliver it to all team members, assigned contractors, and the client associated with that project.
#39
**FRD: Notification Center** > **4\. Functional Logic** > 4.5 Notification Categories and Types > **4.5.2 Messaging Category**
~170 tok
#### **4.5.2 Messaging Category** * When a client or user sends a message through the project messaging system, the system shall trigger the "Message received" notification and deliver it to the intended recipient of the message. * When a user is mentioned using the @ symbol in a conversation or comment, the system shall trigger the "Mentioned you" notification and deliver it specifically to the mentioned user. * When an email is received in the system with full content, the system shall trigger the "Email received" notification with a preview snippet and deliver it to the project owner and associated team members, displaying "Reply" and "Read More" action buttons.
#40
**FRD: Notification Center** > **4\. Functional Logic** > 4.5 Notification Categories and Types > **4.5.3 News and Updates Category**
~66 tok
#### **4.5.3 News and Updates Category** * When Pixally releases new features, improvements, or version updates, the system shall trigger the "Product updates" notification and deliver it to all active users across the platform with a "Learn More" action button.
#41
**FRD: Notification Center** > **4\. Functional Logic** > 4.5 Notification Categories and Types > **4.5.4 System Category**
~231 tok
#### **4.5.4 System Category** * When a new user account is created and the user logs in for the first time, the system shall trigger the "Welcome" notification and deliver it to that specific user as an onboarding message. * When a user's saved payment method is approaching its expiration date, the system shall trigger the "Payment method expiring soon" notification and deliver it to that specific user with an "Update Payment Method" action button. * When a subscription payment fails, the system shall trigger the "Payment failed" notification and deliver it to the Agency Owner and Admin with an "Update Payment Method" action button and a warning about potential account suspension. * When an account is at risk of suspension due to payment issues, the system shall trigger the "Account suspension warning" notification and deliver it to the Agency Owner and all Admin users with urgency indicator styling.
#42
**FRD: Notification Center** > **4\. Functional Logic** > 4.6 Notification Actions and Call-to-Action Buttons
~485 tok
### 4.6 Notification Actions and Call-to-Action Buttons * Notifications of type "Payment request received" shall display two inline action buttons: "Pay Now" styled as a primary button and "Decline" styled as a secondary outlined button. * When the user clicks "Pay Now", the system shall open the payment flow modal or navigate to the payment page without automatically marking the notification as read. * When the user clicks "Decline" on a payment request notification, the system shall display a confirmation dialog asking the user to confirm the decline action before processing. * Notifications of type "Payment request overdue" shall display a "Send Reminder" action button that sends a reminder notification to the client when clicked. * Notifications of type "File uploaded" shall display the file name, file size in human-readable format, and a "Download" action button that initiates a direct browser download of the file when clicked. * Notifications of type "Message received" or "Email received" shall display "Reply" and "Read More" action buttons where Reply opens a compose modal and Read More navigates to the full message view. * Notifications of type "Product updates" shall display a "Learn More" action button that navigates to the feature announcement page when clicked. * Notifications of type "Payment method expiring" or "Payment failed" shall display an "Update Payment Method" action button styled as a primary button that navigates to the payment settings page when clicked. * Action buttons shall display a loading indicator while the associated action is being processed. * Action buttons shall be disabled or hidden when the associated action is no longer valid, such as when a payment has already been completed. * Clicking an action button shall not automatically mark the notification as read; only clicking the notification body or navigating via deep link shall mark it as read.
#43
**FRD: Notification Center** > **4\. Functional Logic** > 4.7 Deep Linking Navigation
~532 tok
### 4.7 Deep Linking Navigation * When the user clicks on a notification item outside of any action buttons, the system shall navigate the user to the relevant module and specific record referenced in the notification. * Clicking a "Questionnaire was filled out" notification shall navigate to the Project detail page with the Questionnaire tab or modal open. * Clicking a "Lead form submitted" notification shall navigate to the Leads module with the specific lead record open. * Clicking a "Proposal was viewed" notification shall navigate to the Project detail page with the Proposal tab open. * Clicking an "Invoice was paid" or "Payment received" notification shall navigate to the Finance module with the specific invoice or payment detail open. * Clicking a "Contract was signed" notification shall navigate to the Project detail page with the Contract tab open. * Clicking a "File uploaded" notification shall navigate to the Project detail page with the Files tab open. * Clicking a "Message received" or "Email received" notification shall navigate to the Project detail page with the Messages or Email tab open. * Clicking a "Task reminder" or "Overdue task" notification shall navigate to the Tasks module with the specific task open. * Clicking a "Post-production" related notification shall navigate to the Post-Production module with the specific job detail open. * Clicking a "Subscription" or "Billing" related notification shall navigate to the Settings page with the Subscription section open. * Clicking a "Security alert" notification shall navigate to the Settings page with the Security section open. * If the entity referenced in a notification has been deleted, the system shall not navigate and shall instead display an inline error message stating "This record no longer exists". * If the user does not have permission to access the target entity, the system shall display an inline error message stating "You don't have permission to view this item". * The Notification Center panel shall close automatically when the user successfully navigates to a deep link target.
#44
**FRD: Notification Center** > **4\. Functional Logic** > 4.8 Mark as Read Functionality
~351 tok
### 4.8 Mark as Read Functionality * When the user clicks on a notification item, the system shall immediately mark that notification as read by updating its read status in the database. * When a notification is marked as read, the system shall decrement the unread count badge on the bell icon by one. * When a notification is marked as read, the system shall update the Unread tab badge count accordingly. * When a notification is marked as read, the system shall update the visual styling of that notification item from unread to read appearance. * When a notification is marked as read while the user is viewing the Unread tab, the system shall remove that notification from the visible list. * When the user clicks "Mark all as read" in the panel header, the system shall mark all notifications as read, not just the currently visible ones. * After marking all as read, the system shall update the bell icon badge to zero or hide it completely. * After marking all as read, the system shall update the Unread tab badge to zero. * After marking all as read while viewing the Unread tab, the system shall display the empty state message "All caught up! No unread notifications." * Read status changes shall be persisted immediately to the database and shall sync across all devices and sessions for the same user. * Read status shall persist across page refreshes and re-logins.
#45
**FRD: Notification Center** > **4\. Functional Logic** > 4.9 Pagination and Load More
~329 tok
### 4.9 Pagination and Load More * When the Notification Center opens, the system shall fetch and display the most recent batch of approximately 50 notifications. * A loading indicator shall be displayed in the panel while the initial notifications are being fetched. * If the user has no notifications, the system shall display an empty state message: "No notifications yet. When you receive notifications, they'll appear here." * When the user scrolls to the bottom of the loaded notification list and more notifications exist, the system shall display a "Load More" button or link. * When the user clicks "Load More", the system shall display an inline loading indicator and fetch the next batch of approximately 50 notifications. * Newly loaded notifications shall be appended to the bottom of the existing list without replacing or reordering the currently displayed notifications. * The user's scroll position shall be maintained after loading more notifications so they can continue from where they were. * When all notifications have been loaded and no more exist, the system shall hide the "Load More" button. * If the Load More operation fails due to a network error, the system shall display an error message "Unable to load more notifications. Please try again." with a retry option.
#46
**FRD: Notification Center** > **4\. Functional Logic** > 4.10 Multi-Agency Contractor Notifications
~373 tok
### 4.10 Multi-Agency Contractor Notifications * Contractors who are associated with multiple agencies shall see notifications from all their associated agencies in a single unified Notification Center without requiring manual agency switching. * Notifications from all agencies shall be combined into a single list and sorted by creation timestamp with the newest first, regardless of which agency generated the notification. * Each notification in a multi-agency contractor's view shall display the agency brand identifier, which may include the agency logo icon or agency name, to help the contractor identify which agency the notification originated from. * The unread notification count displayed on the bell icon badge shall reflect the total unread count across all associated agencies. * When a contractor clicks on a notification from an agency other than their currently active agency context, the system shall automatically switch the contractor's active agency context to match the notification's source agency. * After the agency context switch, the system shall navigate the contractor to the deep link target within the newly active agency's context. * The system shall display a brief toast notification indicating "Switched to \[Agency Name\]" to inform the contractor of the context change. * Similar notifications from multiple agencies shall not be aggregated; each notification shall be displayed as a separate item with its respective agency identifier.
#47
**FRD: Notification Center** > **4\. Functional Logic** > 4.11 Notification Retention and Storage
~222 tok
### 4.11 Notification Retention and Storage * Notifications shall be retained indefinitely with no automatic deletion based on age, ensuring users can access their complete notification history. * Notifications shall always be ordered by creation timestamp with the newest notifications appearing first in the list. * The order shall remain consistent across the All and Unread tabs. * Pagination through Load More shall maintain consistent ordering so that users see notifications in a predictable sequence. * Notifications that reference entities that have been deleted shall remain in the notification list but shall display an error message when clicked. * Notifications for deactivated user accounts shall be archived rather than permanently deleted. * Users cannot manually delete individual notifications from the Notification Center; they can only mark them as read.
#48
**FRD: Notification Center** > **4\. Functional Logic** > 4.12 Page Refresh Updates and Synchronization
~161 tok
### 4.12 Page Refresh Updates and Synchronization * When the user refreshes the page or navigates to the Notification Center, the system shall fetch and display the latest notifications, with any new notifications appearing at the top of the list. * The bell icon badge count shall update upon page load to reflect the current unread notification count. * If a user marks a notification as read on one device, the read status shall sync to the server and be reflected on other devices upon their next page refresh. * The system shall retrieve notification updates from the server on each page load to ensure notifications are current.
#49
**FRD: Notification Center** > **4\. Functional Logic** > 4.12 Real-Time Updates and Synchronization
~158 tok
### 4.12 Real-Time Updates and Synchronization * When a new notification is generated for the user while they have the Notification Center panel open, the system shall prepend the new notification to the top of the list with a highlight animation. * The bell icon badge count shall increment in real-time when new notifications arrive. * If a user marks a notification as read on one device, the read status shall sync to other devices where the user is logged in. * If the real-time notification service is unavailable, the system shall fall back to polling-based updates to ensure notifications are eventually displayed.
#50
**FRD: Notification Center** >
~1 tok
##
#51
**FRD: Notification Center** >
~1 tok
##
#52
**FRD: Notification Center** > **5\. Field Details & Validations**
~523 tok
## **5\. Field Details & Validations** **Field Name** **Field Type** **Validation Rules** notification\_id UUID System-generated unique identifier; primary key; read-only user\_id UUID Required; must reference an existing user in the users table; foreign key agency\_id UUID Required; must reference an existing agency in the agencies table; used for multi-agency contractor filtering category Enum Required; must be one of: PROJECTS\_EVENTS, MESSAGING, NEWS\_UPDATES, SYSTEM type String Required; maximum 100 characters; must match a predefined notification type identifier title String Required; maximum 200 characters; contains the primary notification message body String Optional; maximum 500 characters; contains additional details or preview text created\_at DateTime System-generated; stored in UTC format; indexed for sorting read\_at DateTime Nullable; populated with UTC timestamp when notification is marked as read is\_read Boolean Required; default value is false; indexed for filtering entity\_type Enum Required; identifies the type of referenced entity such as PROJECT, INVOICE, CONTRACT, LEAD, TASK, MESSAGE entity\_id UUID Required; must reference an existing entity of the specified entity\_type deep\_link\_url String Required; maximum 500 characters; must be a valid internal application route has\_cta Boolean Required; default value is false; indicates whether the notification has inline action buttons cta\_config JSON Optional; contains configuration for action buttons including type, label, style, and action endpoint metadata JSON Optional; contains additional notification-specific data as key-value pairs priority Enum Required; default value is NORMAL; allowed values are LOW, NORMAL, HIGH, CRITICAL delivery\_channels Array Required; contains list of channels used: IN\_APP, EMAIL, SMS actor\_id UUID Optional; references the user who triggered the notification; null for system-generated notifications actor\_name String Optional; denormalized display name of the actor for rendering purposes
#53
**FRD: Notification Center** > **6\. Success Message Handling**
~472 tok
## **6\. Success Message Handling** **Operation** **Success Message** **Trigger Condition** **Post-Success Action** Mark all as read "All notifications marked as read" User clicks "Mark all as read" link and the operation completes successfully Update bell icon badge to zero or hide it; update Unread tab badge to zero; refresh notification list styling to show all as read Mark single notification as read No visible message (silent operation) User clicks on a notification item Update notification styling to read state; decrement bell icon badge by one; decrement Unread tab badge by one Navigate via deep link No visible message (silent operation) User clicks notification and navigation succeeds Close Notification Center panel; navigate to target module and record Download file from notification "Download started" User clicks Download button on a file notification Initiate browser file download Pay Now action initiated "Redirecting to payment..." User clicks Pay Now button Open payment flow modal or navigate to payment page Reply action initiated No visible message User clicks Reply button Open compose or reply modal Send Reminder action "Reminder sent successfully" User clicks Send Reminder button and the operation completes Update notification state to indicate reminder was sent Decline payment request "Payment request declined" User confirms decline action in the confirmation dialog Update notification to reflect declined state; remove or disable action buttons Load more notifications No visible message (silent operation) User clicks Load More and fetch completes successfully Append new notifications to list; hide Load More if no more exist Agency context switch "Switched to \[Agency Name\]" (toast notification) Contractor clicks cross-agency notification Switch active agency context; navigate to deep link target
#54
**FRD: Notification Center** > **7\. Error Message Handling**
~651 tok
## **7\. Error Message Handling** **Error Scenario** **Error Message** **Trigger Condition** **User Action Required** **System Response** Referenced entity deleted "This record no longer exists" User clicks notification for an entity that has been deleted None; informational only Display error inline within notification panel; do not navigate Permission denied for entity "You don't have permission to view this item" User clicks notification but lacks access permission to the target entity Contact administrator for access Display error inline within notification panel; do not navigate Failed to load notifications "Unable to load notifications. Please try again." API request to fetch notifications fails due to server error Click retry button or refresh page Display error message with retry button in panel Failed to mark as read "Unable to update notification. Please try again." API request to mark notification as read fails Try the action again Display error toast; revert notification UI to previous state Failed to load more notifications "Unable to load more notifications. Please try again." API request for pagination fails Click Load More again Display error inline below the list; keep existing notifications visible Network connectivity lost "You appear to be offline. Please check your connection." System detects no network connectivity Restore network connection Display offline indicator; disable interactive actions CTA action failed "Unable to complete action. Please try again." API call for an inline action such as Send Reminder fails Try the action again Display error toast; keep action button enabled for retry File download failed "Unable to download file. Please try again." File download request fails Try download again Display error toast Invalid deep link "This page is no longer available" Deep link route does not exist or is malformed None; informational only Display error inline; do not navigate Agency context switch failed "Unable to switch agency. Please try again." Agency context switch operation fails for contractor Try clicking notification again Display error toast; remain in current agency context Session expired "Your session has expired. Please log in again." Authentication token has expired during an action Log in again Redirect to login page Real-time connection lost "Live updates paused. Notifications may be delayed." WebSocket connection to real-time service is lost None; automatic reconnection attempted Fall back to polling; display warning indicator; attempt reconnection
#55
**FRD: Notification Center** > **8\. Edge Cases**
~800 tok
## **8\. Edge Cases** **Edge Case Scenario** **Description** **Expected System Behavior** No notifications exist New user with no activity has zero notifications Display empty state illustration with message: "No notifications yet. When you receive notifications, they'll appear here." All notifications read on Unread tab User marks all as read while viewing Unread tab Display empty state with message: "All caught up! No unread notifications." Extremely high notification volume User receives more than 100 notifications in a short time period Paginate display with Load More; badge displays "99+" when unread count exceeds 99 Rapid new notifications Multiple notifications arrive while panel is open Prepend each new notification to the list with highlight animation; increment badge in real-time Duplicate notification triggers Same event triggers notification multiple times within a short window System deduplicates identical notifications within a 5-minute window; only one notification displayed Concurrent read status updates User marks notification as read on mobile while desktop panel is open Sync read status across devices; desktop UI updates accordingly on next sync Notification content overflow Title or context text exceeds display width Truncate with ellipsis; display full text in tooltip on hover File name overflow Uploaded file has a very long file name Truncate middle portion of filename with ellipsis; preserve file extension Multiple CTAs exceed space Notification has more than two action buttons Display first two CTAs inline; show additional actions in overflow menu CTA action no longer valid User clicks Pay Now but payment was already completed Hide or disable the CTA button; if clicked, display message "This action is no longer available" Deep link to archived entity Notification links to a project that has been archived Navigate to archived view with notice: "This item has been archived" Contractor removed from agency Contractor has notification from agency they were removed from Notification remains visible; deep link displays access denied error New notification while panel open New notification arrives while user is viewing panel Prepend notification to list with highlight; increment badge without disrupting user's view Timezone differences User in different timezone than event Display all timestamps converted to user's local timezone Notification during maintenance System maintenance window is active Queue notifications on server; deliver and display after maintenance completes Very old notifications User scrolls to access notifications from months ago Continue displaying with proper date format "MMM DD, YYYY" for previous year Read status sync failure Network fails after locally marking notification as read Retry sync on reconnection; show warning if sync fails persistently Browser notifications blocked User has blocked browser notification permissions Rely solely on in-app Notification Center; no error displayed Scroll position after tab switch User scrolls down in All tab then switches to Unread Reset scroll position to top when switching tabs Rapid successive clicks
#56
**FRD: Notification Center** > **8\. Edge Cases**
~54 tok
User clicks same notification multiple times quickly Debounce click events; prevent multiple navigation attempts Zero-state badge Unread count reaches exactly zero Hide badge completely rather than displaying "0"
#57
**FRD: Notification Center** > **9\. Acceptance Criteria**
~8 tok
## **9\. Acceptance Criteria**
#58
**FRD: Notification Center** > **9\. Acceptance Criteria** > 9.1 Bell Icon and Badge
~147 tok
### 9.1 Bell Icon and Badge * The bell icon must be visible in the top-right header area on all authenticated screens throughout the application. * The badge must display the correct unread notification count between 1 and 99. * The badge must display "99+" when the unread count exceeds 99. * The badge must be hidden when the unread count is zero. * The badge must update in real-time when new notifications arrive. * The badge must decrement immediately when notifications are marked as read. * Clicking the bell icon must toggle the notification panel open and closed.
#59
**FRD: Notification Center** > **9\. Acceptance Criteria** > 9.2 Notification Panel
~98 tok
### 9.2 Notification Panel * The panel must open as a dropdown overlay when the bell icon is clicked. * The panel header must display "Notifications" title, "Mark all as read" link, and settings gear icon. * Clicking outside the panel must close it. * Clicking the bell icon while the panel is open must close it. * A subtle background overlay must appear when the panel is open.
#60
**FRD: Notification Center** > **9\. Acceptance Criteria** > 9.3 Tab Filtering
~127 tok
### 9.3 Tab Filtering * "All" and "Unread" tabs must be displayed below the header. * "All" tab must be selected by default when the panel opens. * "Unread" tab must display a badge with the unread count. * Switching to "Unread" tab must filter the list to show only unread notifications. * Switching to "All" tab must show all notifications regardless of read status. * Tab switching must be immediate without page reload. * Empty state messages must display correctly for each tab scenario.
#61
**FRD: Notification Center** > **9\. Acceptance Criteria** > 9.4 Notification Display
~134 tok
### 9.4 Notification Display * Notifications must be sorted by timestamp with newest first. * Each notification must display the correct category icon. * Notification title and message must display correctly formatted with actor name in bold. * Timestamps must display in relative format appropriate to the age of the notification. * Context information showing project name must display correctly. * Unread notifications must be visually distinct from read notifications. * Long content must be truncated with ellipsis.
#62
**FRD: Notification Center** > **9\. Acceptance Criteria** > 9.5 Call-to-Action Buttons
~175 tok
### 9.5 Call-to-Action Buttons * Inline CTAs must display for applicable notification types. * "Pay Now" CTA must open the payment flow when clicked. * "Decline" CTA must show confirmation dialog and process decline when confirmed. * "Download" CTA must initiate file download when clicked. * "Reply" CTA must open compose modal when clicked. * "Read More" CTA must navigate to full content when clicked. * "Send Reminder" CTA must send reminder and show success message when clicked. * "Update Payment Method" must navigate to payment settings when clicked. * CTAs must show loading state during processing. * CTAs must be disabled or hidden when the action is no longer valid.
#63
**FRD: Notification Center** > **9\. Acceptance Criteria** > 9.6 Deep Linking
~115 tok
### 9.6 Deep Linking * Clicking a notification must navigate to the correct module and specific record. * Navigation must close the notification panel. * Clicking a notification must mark it as read automatically. * Notifications for deleted entities must show "record no longer exists" error. * Notifications for inaccessible entities must show permission denied error. * All notification types must have correctly configured deep link targets.
#64
**FRD: Notification Center** > **9\. Acceptance Criteria** > 9.7 Mark as Read
~93 tok
### 9.7 Mark as Read * Clicking a notification must mark that individual notification as read. * "Mark all as read" must mark all notifications as read. * Bell icon badge must update immediately after marking as read. * Unread tab badge must update accordingly. * Read status must persist across page refresh. * Read status must sync across multiple devices.
#65
**FRD: Notification Center** > **9\. Acceptance Criteria** > 9.8 Pagination
~114 tok
### 9.8 Pagination * Initial load must display approximately 50 notifications. * "Load More" button must appear at the bottom of the list when more notifications exist. * Clicking "Load More" must fetch and append additional notifications. * Loading indicator must display during the fetch operation. * "Load More" must be hidden when all notifications have been loaded. * Scroll position must be maintained after loading more notifications.
#66
**FRD: Notification Center** > **9\. Acceptance Criteria** > 9.9 Multi-Agency Contractor
~95 tok
### 9.9 Multi-Agency Contractor * Contractors must see notifications from all associated agencies in a unified view. * Agency identifier must be visible on each notification. * Clicking a cross-agency notification must automatically switch the agency context. * Navigation must work correctly after context switch. * Unread count must reflect total across all agencies.
#67
**FRD: Notification Center** > **9\. Acceptance Criteria** > 9.10 Performance and Reliability
~89 tok
### 9.10 Performance and Reliability * Notification panel must open within 500 milliseconds. * Initial notifications must load within 2 seconds. * Real-time updates must work without requiring page refresh. * Error states must display appropriate messages with retry options. * Retry functionality must work correctly for all failed operations.
#68
**FRD: Notification Center** > **10\. Manual Test Cases**
~84 tok
## **10\. Manual Test Cases** The complete manual test cases for the Notification Center module are provided in a separate Excel file. **Test Case Document:** [TestCases-Notification-Center.xlsx](https://docs.google.com/spreadsheets/d/1kk0VtWPrfYGicO9TIKkiVfIze7f8cJlc/edit?usp=drive_link&ouid=105170312247554220827&rtpof=true&sd=true)
#69
**FRD: Notification Center** >
~1 tok
##
#70
**FRD: Notification Center** > **11\. Dependencies**
~614 tok
## **11\. Dependencies** **Dependency Type** **Dependency Name** **Description** **Impact if Unavailable** Internal Module User Management Provides user authentication, role information, and permission data Cannot determine notification visibility or user permissions; module will not function Internal Module Projects Provides project entity data and associations for deep linking Project-related notification deep links will fail; navigation will show error Internal Module Finance & Invoicing Provides invoice and payment entity data for deep linking Finance notification deep links will fail; payment CTAs will not function Internal Module Contracts Provides contract entity data for deep linking Contract notification deep links will fail Internal Module Lead Management Provides lead entity data for deep linking Lead notification deep links will fail Internal Module Tasks Provides task entity data for deep linking Task notification deep links will fail Internal Module Messaging/Email Provides message and email entity data for deep linking Message notification deep links will fail; Reply CTA will not function Internal Module Post-Production Provides job and workflow entity data for deep linking Post-production notification deep links will fail Internal Module Files/Documents Provides file storage and download URLs Download CTA will fail; file notifications will show errors Internal Service Notification Service Backend service that processes, stores, and delivers notifications No notifications will be generated or displayed; complete module failure Internal Service Real-Time Service WebSocket-based service for live notification delivery Fall back to polling; notifications will be delayed; badge updates will lag External Service CDN Content delivery network for static assets including icons Notification category icons may not display Infrastructure Database Primary data store for notification records Complete module failure; no notifications can be read or written Infrastructure Cache (Redis) Caches unread counts and frequently accessed notification data Slower count calculations; increased database load API Notification API REST API endpoints for notification CRUD operations Module will not function; all operations will fail API Entity APIs REST API endpoints for validating entity existence Deep link validation will fail; navigation may encounter errors
#71
**FRD: Notification Center** > **12\. References**
~6 tok
## **12\. References**
#72
**FRD: Notification Center** > **12\. References** > Figma:[https://www.figma.com/design/ej0kxwP45mDKmZCZfAJ5O8/Pixally?node-id=13441-278861&t=b6Vb2HmYBAZOvvUn-0](https://www.figma.com/design/ej0kxwP45mDKmZCZfAJ5O8/Pixally?node-id=13441-278861&t=b6Vb2HmYBAZOvvUn-0)
~61 tok
### Figma:[https://www.figma.com/design/ej0kxwP45mDKmZCZfAJ5O8/Pixally?node-id=13441-278861&t=b6Vb2HmYBAZOvvUn-0](https://www.figma.com/design/ej0kxwP45mDKmZCZfAJ5O8/Pixally?node-id=13441-278861&t=b6Vb2HmYBAZOvvUn-0) ☑️ 2. Company Notifications
#73
**FRD: Company Notifications**
~8 tok
# **FRD: Company Notifications**
#74
**FRD: Company Notifications** > Product: Pixally CRM | Version: 1.0 | Date: December 11, 2025 | Related FRDs: Notification Center, Personal Notifications
~31 tok
### Product: Pixally CRM | Version: 1.0 | Date: December 11, 2025 | Related FRDs: Notification Center, Personal Notifications
#75
**FRD: Company Notifications** >
~1 tok
###
#76
**FRD: Company Notifications** > **1\. Module Overview**
~7 tok
## **1\. Module Overview**
#77
**FRD: Company Notifications** > **1\. Module Overview** > 1.1 Module Name
~11 tok
### 1.1 Module Name Company Notifications
#78
**FRD: Company Notifications** > **1\. Module Overview** > 1.2 Purpose
~139 tok
### 1.2 Purpose The Company Notifications module enables Agency Owners and Admins to configure organization-wide notification settings that establish default behaviors for all users within their agency. This centralized control mechanism allows leadership to define consistent communication standards for client-facing payment reminders, contractor job reminders, project snapshots, and internal team alerts. Company Notification settings serve as baseline defaults that can be overridden by individual users through their Personal Notification settings.
#79
**FRD: Company Notifications** > **1\. Module Overview** > 1.3 Business Goals
~219 tok
### 1.3 Business Goals * Provide Agency Owners and Admins with centralized control to configure company-wide notification defaults from a single administrative interface. * Ensure all clients receive standardized payment reminder communications according to the company's defined schedule and policies. * Enable systematic reminder schedules for contractors regarding upcoming jobs to maintain operational readiness and reduce no-shows. * Establish default notification behaviors for internal team members to ensure consistent awareness of important business events such as lead follow-ups and task completions. * Allow business owners to configure notification timing that aligns with their specific business processes and client communication preferences. * Gate advanced notification features based on subscription tiers to drive plan upgrades and monetization.
#80
**FRD: Company Notifications** > **2\. User Roles & Permissions**
~9 tok
## **2\. User Roles & Permissions**
#81
**FRD: Company Notifications** > **2\. User Roles & Permissions** > 2.1 Roles with Access to Company Notifications
~140 tok
### 2.1 Roles with Access to Company Notifications **Role** **View Company Notifications Tab** **Modify Company Settings** **Configure Payment Reminders** **Configure Contractor Reminders** **Configure Snapshot** **Configure Internal Reminders** Agency Owner Yes Yes Yes Yes Yes Yes Admin Yes Yes Yes Yes Yes Yes Project Manager No No No No No No Normal User (Staff) No No No No No No Editor No No No No No No Contractor No No No No No No Client No No No No No No Gawd Portal User No No No No No No
#82
**FRD: Company Notifications** > **2\. User Roles & Permissions** > 2.2 Permission Details
~203 tok
### 2.2 Permission Details * Only Agency Owner and Admin roles can view the "Company Notifications" tab in the Notification Settings page. * Users with any other role will see only the "Personal Notifications" tab when accessing Settings > Notifications. * The Company Notifications tab is completely hidden for unauthorized users rather than being displayed as disabled. * Both Agency Owner and Admin have identical permissions within Company Notifications with no hierarchy between them. * Multiple Admins and Agency Owners can access and edit Company Notifications simultaneously using a last-write-wins approach for concurrent edits. * If a non-authorized user attempts to access the Company Notifications URL directly, they shall be redirected to Personal Notifications with an error message.
#83
**FRD: Company Notifications** > **3\. User Flow**
~603 tok
## **3\. User Flow** 3.1 The Agency Owner or Admin logs into Pixally CRM and navigates to the Settings area from the main navigation menu. 3.2 The system displays the Settings page with various configuration options in the sidebar. 3.3 The user clicks on "Notifications" in the settings sidebar. 3.4 The system loads the Notification Settings page and displays two tabs: "Personal Notifications" and "Company Notifications". 3.5 The user clicks on the "Company Notifications" tab. 3.6 The system displays the Company Notifications settings panel with all configurable sections: Payment Reminders, Contractor Reminders, Snapshot, and Internal Team Reminders. 3.7 The user locates the Payment Reminders section showing four reminder types: Upcoming, Due date, Overdue (+2 days), and Overdue (+5 days). 3.8 The user clicks on the SMS toggle for the "Upcoming" payment reminder to enable SMS delivery. 3.9 The system immediately saves the setting and displays a brief success indicator confirming the change. 3.10 The user clicks on the Email toggle for the same reminder to enable both SMS and Email delivery simultaneously. 3.11 The system saves the multi-channel selection and confirms the update. 3.12 The user scrolls to the Contractor Reminders section showing two reminder types: 2 days before and 7 days before event. 3.13 The user enables SMS and Email for the 7-day contractor reminder. 3.14 The system saves the contractor reminder settings. 3.15 The user locates the Snapshot section with a toggle for "Send automatically one day before events". 3.16 The user enables the Snapshot toggle. 3.17 The system saves the setting and displays confirmation that snapshots will be sent automatically before events. 3.18 The user scrolls to the Internal Team Reminders section. 3.19 The user locates the lead response alert setting with a dropdown for configuring the number of days. 3.20 The user changes the dropdown value from 7 days to 5 days. 3.21 The system saves the updated lead response threshold. 3.22 The user enables In-App and Email for the task due date reminder. 3.23 The system saves the internal reminder settings. 3.24 The user navigates away from the Company Notifications page. 3.25 Another Admin logs in and navigates to Company Notifications. 3.26 The system displays the same settings configured by the first admin, reflecting the shared company-wide configuration.
#84
**FRD: Company Notifications** > **4\. Functional Logic**
~7 tok
## **4\. Functional Logic**
#85
**FRD: Company Notifications** > **4\. Functional Logic** > 4.1 Access and Visibility Rules
~280 tok
### 4.1 Access and Visibility Rules * The Notification Settings page shall display two tabs when accessed by an Agency Owner or Admin: "Personal Notifications" and "Company Notifications". * The "Company Notifications" tab shall be completely hidden and not rendered for users with Project Manager, Staff, Editor, Contractor, Client, or Gawd Portal roles. * Users without Agency Owner or Admin roles shall see only the "Personal Notifications" content without any tab interface when accessing Settings > Notifications. * Tab visibility shall be determined by the user's role at the time of page load, and a role change requires a page refresh to update the visible tabs. * If a user without proper authorization attempts to access the Company Notifications URL directly through browser manipulation, the system shall redirect them to the Personal Notifications page and display an error message stating "You don't have permission to access company notification settings". * The Company Notifications settings shall be accessible at the navigation path: Settings > Notifications > Company Notifications tab.
#86
**FRD: Company Notifications** > **4\. Functional Logic** > 4.2 Company Settings Override Behavior
~342 tok
### 4.2 Company Settings Override Behavior * Company Notification settings shall establish the default notification preferences that apply to all users within the organization. * When a new user is created or joins the agency, their personal notification settings shall be initialized with the current company default values. * Company settings shall not lock or prevent users from customizing their own preferences in Personal Notifications; users can always override company defaults. * When determining which setting to apply for a specific notification, the system shall use the following priority hierarchy: Personal Notification setting takes highest priority if the user has customized it, Company Notification setting applies if the user has not customized that specific preference, and System Default applies if no company setting exists. * When an Admin or Agency Owner updates a Company Notification setting, the change shall apply immediately to all users who have not customized that specific setting in their Personal Notifications. * Company setting updates shall not retroactively change or overwrite existing personal customizations that users have already made. * For notification types not configured at the company level during initial setup, system defaults shall apply with all notifications enabled via In-App and Email channels.
#87
**FRD: Company Notifications** > **4\. Functional Logic** > 4.3 Multi-Admin Concurrent Editing
~199 tok
### 4.3 Multi-Admin Concurrent Editing * Multiple Admins or Agency Owners can access and view the Company Notifications settings page simultaneously without any locking mechanism. * The system shall use a "last write wins" approach when multiple administrators save conflicting changes to the same setting. * When Admin A saves a setting while Admin B is viewing the same page, Admin A's change shall be persisted immediately to the database. * Admin B's view shall not automatically update in real-time; Admin B must refresh the page to see changes made by Admin A. * If Admin B makes a subsequent change without refreshing, Admin B's change shall overwrite Admin A's previous change. * The system shall not display any conflict notification or warning when concurrent edits occur.
#88
**FRD: Company Notifications** > **4\. Functional Logic** > 4.4 Payment Reminders Configuration
~10 tok
### 4.4 Payment Reminders Configuration
#89
**FRD: Company Notifications** > **4\. Functional Logic** > 4.4 Payment Reminders Configuration > **4.4.1 Payment Reminder Types and Timing**
~188 tok
#### **4.4.1 Payment Reminder Types and Timing** * The system shall provide four configurable payment reminder types that are sent to clients regarding their invoice payments. * The "Upcoming" payment reminder shall be triggered and delivered 7 days prior to the invoice due date to give clients advance notice. * The "Due date" payment reminder shall be triggered and delivered on the exact payment due date as a same-day reminder. * The "Overdue (+2 days)" payment reminder shall be triggered and delivered 2 days after the invoice due date has passed as a first overdue notice. * The "Overdue (+5 days)" payment reminder shall be triggered and delivered 5 days after the invoice due date has passed as a second overdue escalation notice.
#90
**FRD: Company Notifications** > **4\. Functional Logic** > 4.4 Payment Reminders Configuration > **4.4.2 Payment Reminder Trigger Logic and Recipients**
~328 tok
#### **4.4.2 Payment Reminder Trigger Logic and Recipients** * When an invoice is created with a due date, the system shall schedule the applicable payment reminders based on the company's enabled reminder types and channels. * The Upcoming payment reminder shall be triggered when the system date reaches 7 days before the invoice due date, and shall be delivered to the primary client contact associated with the invoice. * The Due date payment reminder shall be triggered when the system date matches the invoice due date, and shall be delivered to the primary client contact associated with the invoice. * The Overdue (+2 days) payment reminder shall be triggered when the system date reaches 2 days past the invoice due date and the invoice remains unpaid, and shall be delivered to the primary client contact. * The Overdue (+5 days) payment reminder shall be triggered when the system date reaches 5 days past the invoice due date and the invoice remains unpaid, and shall be delivered to the primary client contact. * If the client completes payment before a scheduled reminder is due to be sent, the system shall cancel that reminder and not deliver it. * If a payment attempt fails, separate payment failure notifications shall be triggered independently from these reminder schedules.
#91
**FRD: Company Notifications** > **4\. Functional Logic** > 4.4 Payment Reminders Configuration > **4.4.3 Payment Reminder Channel Options**
~190 tok
#### **4.4.3 Payment Reminder Channel Options** * Each payment reminder type shall have three channel options displayed as toggle buttons: None, SMS, and Email. * The SMS and Email channels shall function as independent toggles that can be enabled simultaneously, allowing multi-channel delivery. * When both SMS and Email are enabled for a reminder type, the client shall receive the reminder through both channels when triggered. * Selecting "None" shall disable the reminder entirely, preventing delivery through any channel. * The default setting for all payment reminder types shall be SMS and Email both enabled. * SMS delivery requires that the client has a valid phone number on file; if no phone number exists, only email shall be sent.
#92
**FRD: Company Notifications** > **4\. Functional Logic** > 4.5 Contractor Reminders Configuration
~11 tok
### 4.5 Contractor Reminders Configuration
#93
**FRD: Company Notifications** > **4\. Functional Logic** > 4.5 Contractor Reminders Configuration > **4.5.1 Contractor Reminder Types and Timing**
~122 tok
#### **4.5.1 Contractor Reminder Types and Timing** * The system shall provide two configurable contractor reminder types that are sent to contractors regarding their upcoming assigned jobs. * The "Upcoming Job Reminder (7 days before)" shall be triggered and delivered 7 days prior to the event date to give contractors advance notice. * The "Upcoming Job Reminder (2 days before)" shall be triggered and delivered 2 days prior to the event date as a final confirmation reminder.
#94
**FRD: Company Notifications** > **4\. Functional Logic** > 4.5 Contractor Reminders Configuration > **4.5.2 Contractor Reminder Trigger Logic and Recipients**
~304 tok
#### **4.5.2 Contractor Reminder Trigger Logic and Recipients** * When a contractor is assigned to a project with an event date, the system shall schedule the applicable contractor reminders based on the company's enabled reminder types and channels. * The 7-day contractor reminder shall be triggered when the system date reaches 7 days before the assigned event date, and shall be delivered to the contractor assigned to that specific event. * The 2-day contractor reminder shall be triggered when the system date reaches 2 days before the assigned event date, and shall be delivered to the contractor assigned to that specific event. * If multiple contractors are assigned to the same event, each contractor shall receive their own individual reminder. * If a contractor is removed from a project before the scheduled reminder date, the system shall cancel the pending reminders for that contractor. * Contractor reminders shall include essential event details in the notification content: event date, time, location, project name, and assigned role. * The 2-day reminder may include a request for the contractor to confirm their attendance, and SMS responses can be tracked for confirmation status.
#95
**FRD: Company Notifications** > **4\. Functional Logic** > 4.5 Contractor Reminders Configuration > **4.5.3 Contractor Reminder Channel Options**
~129 tok
#### **4.5.3 Contractor Reminder Channel Options** * Each contractor reminder type shall have three channel options: None, SMS, and Email. * SMS and Email can be enabled simultaneously for multi-channel delivery to contractors. * Selecting "None" shall disable that specific reminder timing entirely. * The default setting for contractor reminders shall be SMS and Email both enabled. * SMS confirmations from contractors shall be tracked and displayed on the contractor dashboard and project detail page.
#96
**FRD: Company Notifications** > **4\. Functional Logic** > 4.6 Snapshot Configuration
~8 tok
### 4.6 Snapshot Configuration
#97
**FRD: Company Notifications** > **4\. Functional Logic** > 4.6 Snapshot Configuration > **4.6.1 Snapshot Purpose and Content**
~171 tok
#### **4.6.1 Snapshot Purpose and Content** * The Snapshot feature shall generate and send a comprehensive PDF document to contractors containing all vital project information before their assigned events. * The Snapshot PDF shall include: event date and time, event location and venue address, client contact information, project owner contact information, event timeline and schedule, contractor's assigned role, special instructions or notes, names of other assigned team members, and emergency contact information. * The Snapshot is designed for contractors who may not have reliable internet access at event locations, providing them with offline-accessible information.
#98
**FRD: Company Notifications** > **4\. Functional Logic** > 4.6 Snapshot Configuration > **4.6.2 Snapshot Trigger Logic and Recipients**
~235 tok
#### **4.6.2 Snapshot Trigger Logic and Recipients** * When the Snapshot setting is enabled and the system date reaches 1 day before an event date, the system shall trigger snapshot generation for all contractors assigned to that event. * The generated Snapshot PDF shall be delivered via email to each assigned contractor's registered email address. * One unique Snapshot shall be generated per contractor per event, personalized with that contractor's specific role and relevant information. * If a contractor is assigned to multiple events on the same day, they shall receive multiple separate Snapshot PDFs, one for each event. * If a contractor is removed from the project before the Snapshot delivery date, the system shall not generate or send a Snapshot to that contractor. * If Snapshot generation fails due to a technical error, the failure shall be logged and administrators can manually trigger Snapshot generation.
#99
**FRD: Company Notifications** > **4\. Functional Logic** > 4.6 Snapshot Configuration > **4.6.3 Snapshot Settings**
~118 tok
#### **4.6.3 Snapshot Settings** * The Snapshot section shall display a single toggle setting labeled "Send automatically one day before events". * The toggle shall have two states: Off (disabled) and On (enabled). * The timing of 1 day before the event is fixed and not configurable in the current version. * Snapshot delivery uses email only since it involves a PDF attachment; SMS is not applicable. * The default setting for Snapshot shall be Off (disabled).
#100
**FRD: Company Notifications** > **4\. Functional Logic** > 4.7 Internal Team Reminders Configuration
~11 tok
### 4.7 Internal Team Reminders Configuration
#101
**FRD: Company Notifications** > **4\. Functional Logic** > 4.7 Internal Team Reminders Configuration > **4.7.1 Internal Reminder Types**
~166 tok
#### **4.7.1 Internal Reminder Types** * The system shall provide four configurable internal team reminder types that are sent to agency staff members. * The "Event reminder (1 week before)" shall notify the primary user about upcoming event dates on their assigned projects. * The "Lead response alert" shall notify the primary user when a new lead has not been responded to within a configurable number of days. * The "Task due date reminder" shall notify the task assignee when their assigned task reaches its due date. * The "Task completed notification" shall notify the user who created a task when that task is marked as completed by the assignee.
#102
**FRD: Company Notifications** > **4\. Functional Logic** > 4.7 Internal Team Reminders Configuration > **4.7.2 Internal Reminder Trigger Logic and Recipients**
~333 tok
#### **4.7.2 Internal Reminder Trigger Logic and Recipients** * The Event reminder (1 week before) shall be triggered when the system date reaches 7 days before a project's event date, and shall be delivered to the primary user designated on that project. * The Lead response alert shall be triggered when a lead's age exceeds the configured threshold (default 7 days) without any response activity, and shall be delivered to the Agency Owner, Admin, or designated lead handler. * A lead shall be considered "responded to" when any of the following actions occur: an email is sent to the lead from within Pixally, a phone call is logged against the lead, the lead status is changed to "Contacted" or a subsequent status, or a proposal is sent to the lead. * Simply viewing the lead record shall not count as a response for the purposes of the lead response alert. * The Lead response alert shall trigger only once per lead; it shall not repeat for the same lead. * The Task due date reminder shall be triggered when the system date matches a task's due date and the task is not yet completed, and shall be delivered to the user assigned to that task. * The Task completed notification shall be triggered when a task's status is changed to completed, and shall be delivered to the user who originally created that task.
#103
**FRD: Company Notifications** > **4\. Functional Logic** > 4.7 Internal Team Reminders Configuration > **4.7.3 Lead Response Alert Days Configuration**
~124 tok
#### **4.7.3 Lead Response Alert Days Configuration** * The Lead response alert shall include a dropdown selector allowing administrators to configure the number of days threshold. * The dropdown shall offer the following options: 3 days, 5 days, 7 days, 10 days, and 14 days. * The default value for the lead response days shall be 7 days. * When the dropdown value is changed, the system shall immediately save the new threshold and apply it to all future lead response calculations.
#104
**FRD: Company Notifications** > **4\. Functional Logic** > 4.7 Internal Team Reminders Configuration > **4.7.4 Internal Reminder Channel Options**
~126 tok
#### **4.7.4 Internal Reminder Channel Options** * Each internal reminder type shall have three channel options: None, In-App, and Email. * In-App and Email can be enabled simultaneously for multi-channel delivery to staff members. * Selecting "None" shall disable that specific internal reminder entirely. * The default setting for all internal reminders shall be In-App and Email both enabled. * SMS is not available for internal team reminders; only In-App and Email channels are offered.
#105
**FRD: Company Notifications** > **4\. Functional Logic** > 4.8 Subscription-Based Feature Restrictions
~325 tok
### 4.8 Subscription-Based Feature Restrictions * Certain Company Notification features shall be gated based on the agency's current subscription tier. * Payment Reminders shall be available to all subscribers on the base plan with no additional subscription required. * Contractor Reminders shall require the Contractor Portal add-on subscription; without this subscription, the Contractor Reminders section shall be hidden or displayed as disabled with an upgrade prompt. * Snapshot configuration shall require the Contractor Portal add-on subscription; without this subscription, the Snapshot section shall be hidden or displayed as disabled. * Internal Team Reminders shall be available to all subscribers on the base plan. * The SMS delivery channel shall require the SMS add-on subscription; without this subscription, the SMS toggle shall be disabled with a tooltip indicating "SMS notifications require an active SMS add-on subscription". * Features requiring a higher subscription tier shall display a lock icon and "Upgrade" link that navigates to the subscription settings page. * Subscription status shall be validated at page load, and if a subscription lapses mid-session, existing saved settings shall remain but shall not be enforced until the subscription is renewed.
#106
**FRD: Company Notifications** > **4\. Functional Logic** > 4.9 Settings Auto-Save Behavior
~216 tok
### 4.9 Settings Auto-Save Behavior * All Company Notification setting changes shall be automatically saved immediately upon user interaction with any toggle, dropdown, or control. * No explicit "Save" button shall be required or displayed for saving Company Notification settings. * When a setting is successfully saved, a brief visual indicator such as a checkmark animation or success toast shall appear to confirm the save. * If a save operation fails due to a network error or server issue, the UI shall revert to the previous setting state and display an error message "Unable to save setting. Please try again." * Company Notification settings shall be stored at the agency level, associated with the agency\_id rather than individual user IDs. * All Admins and Agency Owners access and modify the same shared settings record for their agency.
#107
**FRD: Company Notifications** > **5\. Field Details & Validations**
~713 tok
## **5\. Field Details & Validations** **Field Name** **Field Type** **Validation Rules** setting\_id UUID System-generated unique identifier; primary key agency\_id UUID Required; must reference an existing agency; foreign key; one settings record per agency created\_at DateTime System-generated timestamp when settings record was created updated\_at DateTime System-updated timestamp on any setting modification updated\_by UUID Required on update; must reference a valid user ID; tracks last modifier payment\_reminder\_upcoming\_sms Boolean Default: true; enables SMS for upcoming payment reminder payment\_reminder\_upcoming\_email Boolean Default: true; enables Email for upcoming payment reminder payment\_reminder\_due\_sms Boolean Default: true; enables SMS for due date payment reminder payment\_reminder\_due\_email Boolean Default: true; enables Email for due date payment reminder payment\_reminder\_overdue\_2\_sms Boolean Default: true; enables SMS for +2 days overdue reminder payment\_reminder\_overdue\_2\_email Boolean Default: true; enables Email for +2 days overdue reminder payment\_reminder\_overdue\_5\_sms Boolean Default: true; enables SMS for +5 days overdue reminder payment\_reminder\_overdue\_5\_email Boolean Default: true; enables Email for +5 days overdue reminder contractor\_reminder\_2day\_sms Boolean Default: true; enables SMS for 2-day contractor reminder contractor\_reminder\_2day\_email Boolean Default: true; enables Email for 2-day contractor reminder contractor\_reminder\_7day\_sms Boolean Default: true; enables SMS for 7-day contractor reminder contractor\_reminder\_7day\_email Boolean Default: true; enables Email for 7-day contractor reminder snapshot\_enabled Boolean Default: false; enables automatic snapshot delivery snapshot\_days\_before Integer Default: 1; fixed value in current version; days before event to send snapshot event\_reminder\_week\_before\_inapp Boolean Default: true; enables In-App for weekly event reminder event\_reminder\_week\_before\_email Boolean Default: true; enables Email for weekly event reminder lead\_response\_alert\_inapp Boolean Default: true; enables In-App for lead response alert lead\_response\_alert\_email Boolean Default: true; enables Email for lead response alert lead\_response\_alert\_days Integer Default: 7; allowed values: 3, 5, 7, 10, 14; days threshold for lead response task\_due\_reminder\_inapp Boolean Default: true; enables In-App for task due reminder task\_due\_reminder\_email Boolean Default: true; enables Email for task due reminder task\_completed\_notification\_inapp Boolean Default: true; enables In-App for task completed notification task\_completed\_notification\_email Boolean Default: true; enables Email for task completed notification
#108
**FRD: Company Notifications** > **6\. Success Message Handling**
~535 tok
## **6\. Success Message Handling** **Operation** **Success Message** **Trigger Condition** **Post-Success Action** Enable payment reminder SMS "Payment reminder settings updated" User enables SMS toggle for any payment reminder type Save setting to database; display brief checkmark indicator Enable payment reminder Email "Payment reminder settings updated" User enables Email toggle for any payment reminder type Save setting to database; display brief checkmark indicator Disable payment reminder channel "Payment reminder settings updated" User disables SMS or Email for a payment reminder Save setting to database; update toggle visual state Select None for payment reminder "Payment reminder settings updated" User selects None, disabling all channels for a reminder Save setting; deselect both SMS and Email toggles Enable contractor reminder "Contractor reminder settings updated" User enables SMS or Email for contractor reminder Save setting to database; update UI state Disable contractor reminder "Contractor reminder settings updated" User selects None for a contractor reminder Save setting; disable that reminder timing Enable snapshot "Snapshot will be sent automatically before events" User toggles Snapshot to On Save setting; display confirmation message Disable snapshot "Snapshot has been disabled" User toggles Snapshot to Off Save setting; update toggle visual state Update lead response days "Lead response alert updated to \[X\] days" User changes dropdown selection Save new threshold; apply to future calculations Enable internal reminder In-App "Reminder settings updated" User enables In-App for any internal reminder Save setting to database Enable internal reminder Email "Reminder settings updated" User enables Email for any internal reminder Save setting to database Disable internal reminder "Reminder settings updated" User disables an internal reminder channel Save setting; update toggle state Any setting auto-saved Brief checkmark animation (no text) Any toggle or dropdown change saved successfully Visual feedback without modal interruption
#109
**FRD: Company Notifications** > **7\. Error Message Handling**
~572 tok
## **7\. Error Message Handling** **Error Scenario** **Error Message** **Trigger Condition** **User Action Required** **System Response** Unauthorized access attempt "You don't have permission to access company notification settings" Non-admin user attempts to access Company Notifications via direct URL None; automatic redirect Redirect user to Personal Notifications page Failed to load settings "Unable to load company notification settings. Please try again." API request to fetch company settings fails Refresh page or click retry button Display error message with retry button Failed to save setting "Unable to save setting. Please try again." API request to save a setting change fails Try making the change again Revert toggle/dropdown to previous state; display error toast SMS subscription required "SMS notifications require an active SMS add-on subscription" User attempts to enable SMS without SMS subscription Upgrade subscription to add SMS Disable SMS toggle; display tooltip with upgrade link Contractor Portal subscription required "Contractor reminders require the Contractor Portal subscription" User without Contractor Portal tries to access contractor settings Upgrade subscription Hide or disable contractor reminder section; show upgrade prompt Network connectivity lost "You appear to be offline. Changes cannot be saved." System detects no network connectivity Restore network connection Disable all toggles and dropdowns; show offline indicator Invalid dropdown selection "Invalid selection. Please choose from available options." Corrupted or tampered dropdown value submitted Select a valid option from dropdown Reject save; revert dropdown to previous valid value Session expired "Your session has expired. Please log in again." Authentication token expired during interaction Log in again Redirect to login page Agency record not found "Company settings could not be found. Please contact support." Agency record is missing or database error Contact support Display error; prevent any setting changes Lead response days out of range "Please select a valid number of days (3, 5, 7, 10, or 14)" Invalid day value submitted outside allowed options Select valid option Reject save; maintain previous value
#110
**FRD: Company Notifications** > **8\. Edge Cases**
~785 tok
## **8\. Edge Cases** **Edge Case Scenario** **Description** **Expected System Behavior** New agency first access Agency created but no company notification settings exist yet System creates default settings record with all reminders enabled and default values applied First admin configures settings Admin accesses Company Notifications for the first time Load default settings; all reminders enabled with SMS/Email or In-App/Email defaults All payment reminders disabled Admin selects None for all four payment reminder types System allows this configuration; clients receive no payment reminders at all SMS integration not configured Agency enables SMS reminders but hasn't set up SMS integration Display warning: "SMS delivery requires SMS integration setup. Email will be used as fallback." Two admins edit simultaneously Admin A and Admin B save different values for the same setting within seconds Last save wins; no merge or conflict resolution; Admin A's change may be overwritten Admin role downgraded User with Admin role is downgraded to Project Manager while viewing Company Notifications On next navigation or save attempt, redirect to Personal Notifications with access denied message User upgraded to Admin Project Manager is promoted to Admin role Company Notifications tab appears after page refresh Subscription downgraded Agency downgrades from plan that included Contractor Portal Contractor Reminders and Snapshot sections become hidden or disabled; saved settings preserved but not enforced Subscription upgraded Agency upgrades to plan including Contractor Portal Contractor Reminders and Snapshot sections become visible with default values or previously saved values No upcoming events exist Agency has no projects with future event dates Settings save successfully; reminders will trigger when events are created No contractors assigned Agency has no contractors but configures contractor reminders Settings save successfully; reminders will trigger when contractors are assigned to events Lead exactly at threshold Lead age is exactly 7 days (matching configured threshold) Lead response alert triggers on the threshold day Lead responded then status reverted Lead status changed back after being marked as responded Alert may not re-trigger depending on response log; system checks response history Same-day event and snapshot Event is scheduled for today but snapshot wasn't sent Snapshot timing missed; manual snapshot sending may be available to admins Contractor assigned to multiple same-day events Contractor has three events scheduled on the same day Contractor receives three separate Snapshot PDFs and individual reminders for each event Agency timezone differs from system Agency configured in PST but server runs in UTC Reminder timing calculations use agency's configured timezone Admin who updated settings is deleted Admin user who last updated settings is later deactivated Settings remain intact; updated\_by field references deactivated user Page refresh during dropdown selection Admin refreshes page while dropdown is open and unsaved
#111
**FRD: Company Notifications** > **8\. Edge Cases**
~91 tok
Unsaved dropdown selection lost; page reloads with last saved state Browser back button after changes Admin uses browser back button after making setting changes Changes already auto-saved; navigation proceeds normally Very long agency name in snapshot Agency name affects PDF snapshot layout Agency name truncated or wrapped appropriately in generated PDF
#112
**FRD: Company Notifications** > **9\. Acceptance Criteria**
~8 tok
## **9\. Acceptance Criteria**
#113
**FRD: Company Notifications** > **9\. Acceptance Criteria** > 9.1 Access and Visibility
~111 tok
### 9.1 Access and Visibility * The "Company Notifications" tab must be visible only to users with Agency Owner or Admin roles. * Users with Project Manager, Staff, Editor, Contractor, Client roles must not see the Company Notifications tab. * Direct URL access by unauthorized users must redirect to Personal Notifications with an error message. * The tab must appear immediately for authorized users without additional loading delay.
#114
**FRD: Company Notifications** > **9\. Acceptance Criteria** > 9.2 Payment Reminders
~134 tok
### 9.2 Payment Reminders * All four payment reminder types must be displayed with their timing descriptions: Upcoming (7 days before), Due date, Overdue (+2 days), Overdue (+5 days). * Each reminder must display None, SMS, and Email channel options. * SMS and Email must be selectable simultaneously for multi-channel delivery. * Selecting "None" must deselect both SMS and Email for that reminder. * All changes must auto-save without requiring a save button. * Visual confirmation must appear after each successful save.
#115
**FRD: Company Notifications** > **9\. Acceptance Criteria** > 9.3 Contractor Reminders
~91 tok
### 9.3 Contractor Reminders * Both contractor reminder types must be displayed: 2 days before event and 7 days before event. * None, SMS, and Email options must be available for each reminder. * Multiple channels must be selectable simultaneously. * Settings must be gated based on Contractor Portal subscription. * Changes must auto-save successfully.
#116
**FRD: Company Notifications** > **9\. Acceptance Criteria** > 9.4 Snapshot
~86 tok
### 9.4 Snapshot * Snapshot toggle must be displayed with description "Send automatically one day before events". * Toggle must switch between On and Off states. * Setting must be gated based on Contractor Portal subscription. * Description must clearly explain snapshot contents and timing. * Change must auto-save with confirmation.
#117
**FRD: Company Notifications** > **9\. Acceptance Criteria** > 9.5 Internal Team Reminders
~87 tok
### 9.5 Internal Team Reminders * All four internal reminder settings must be displayed with descriptions. * None, In-App, and Email options must be available for each reminder. * Lead response days dropdown must contain options: 3, 5, 7, 10, 14 days. * Default dropdown value must be 7 days. * All changes must auto-save successfully.
#118
**FRD: Company Notifications** > **9\. Acceptance Criteria** > 9.6 Override Behavior
~89 tok
### 9.6 Override Behavior * Company settings must establish defaults for new users joining the agency. * Existing users' personal customizations must not be overwritten by company setting changes. * Users who have not customized a setting must receive the company default. * Personal Notification settings must be able to override company defaults.
#119
**FRD: Company Notifications** > **9\. Acceptance Criteria** > 9.7 Multi-Admin Behavior
~78 tok
### 9.7 Multi-Admin Behavior * All Admins and Agency Owners must see the same settings values. * Changes by one admin must be visible to other admins after page refresh. * Last save must win for concurrent edits without data corruption. * No locking mechanism or conflict warnings must be implemented.
#120
**FRD: Company Notifications** > **9\. Acceptance Criteria** > 9.8 Subscription Gating
~76 tok
### 9.8 Subscription Gating * Features requiring higher subscription tiers must be properly gated. * Gated features must show upgrade prompts or be hidden. * SMS toggle must be disabled without SMS add-on subscription. * Contractor features must be hidden without Contractor Portal subscription.
#121
**FRD: Company Notifications** > **9\. Acceptance Criteria** > 9.9 Error Handling
~61 tok
### 9.9 Error Handling * Failed saves must show error message and revert UI to previous state. * Network offline must disable editing and show warning message. * Unauthorized access attempts must redirect appropriately with error message.
#122
**FRD: Company Notifications** > **10\. Manual Test Cases**
~85 tok
## **10\. Manual Test Cases** The complete manual test cases for the Company Notifications module are provided in a separate Excel file. **Test Case Document:** [TestCases-Company-Notifications.xlsx](https://docs.google.com/spreadsheets/d/1qW17OggT51vFs_nG22-VCfndfk6bTGJJ/edit?usp=drive_link&ouid=105170312247554220827&rtpof=true&sd=true)
#123
**FRD: Company Notifications** > **11\. Dependencies**
~628 tok
## **11\. Dependencies** **Dependency Type** **Dependency Name** **Description** **Impact if Unavailable** Internal Module User Management Provides user authentication and role verification for access control Cannot verify if user has Admin/Owner role; access control will fail Internal Module Subscription Management Provides subscription tier information for feature gating Cannot properly gate Contractor Portal or SMS features; all features may display Internal Module Agency/Company Settings Provides agency entity for settings association Cannot save or load company notification settings Internal Module Notification Service Backend service that schedules and delivers reminder notifications Settings save but reminders will not be triggered or delivered Internal Module Invoice/Payment Module Provides invoice due date data for payment reminder scheduling Payment reminders have no data to trigger from; reminders will not schedule Internal Module Projects Module Provides event date data for contractor and snapshot scheduling Contractor reminders and snapshots have no event data; will not trigger Internal Module Contractor Management Provides contractor assignment data for reminder targeting Contractor reminders have no recipient information; cannot deliver Internal Module Lead Management Provides lead data and response tracking for lead alerts Lead response alerts cannot check lead status; will not trigger Internal Module Tasks Module Provides task assignment and due date data for task reminders Task reminders have no task data; will not trigger External Service SMS Service (Twilio) Delivers SMS notifications to clients and contractors SMS channel delivery fails; email used as fallback if available External Service Email Service (SendGrid/SES) Delivers email notifications and snapshot PDFs Email channel delivery fails; notifications not sent External Service PDF Generation Service Generates Snapshot PDF documents for contractors Snapshot generation fails; contractors do not receive pre-event PDFs Infrastructure Database Stores company notification settings Complete module failure; cannot load or save any settings Infrastructure Background Job Processor Schedules and executes reminder deliveries at configured times Reminders do not trigger at scheduled times; all timing-based notifications fail API Company Settings API REST endpoints for settings CRUD operations Cannot load or save company notification settings
#124
**FRD: Company Notifications** > **12\. References**
~6 tok
## **12\. References**
#125
**FRD: Company Notifications** > **12\. References** > Figma:
~3 tok
### Figma:
#126
**FRD: Company Notifications** > **12\. References** > [https://www.figma.com/design/ej0kxwP45mDKmZCZfAJ5O8/Pixally?node-id=33524-68507&t=b6Vb2HmYBAZOvvUn-0](https://www.figma.com/design/ej0kxwP45mDKmZCZfAJ5O8/Pixally?node-id=33524-68507&t=b6Vb2HmYBAZOvvUn-0)
~60 tok
### [https://www.figma.com/design/ej0kxwP45mDKmZCZfAJ5O8/Pixally?node-id=33524-68507&t=b6Vb2HmYBAZOvvUn-0](https://www.figma.com/design/ej0kxwP45mDKmZCZfAJ5O8/Pixally?node-id=33524-68507&t=b6Vb2HmYBAZOvvUn-0) ☑️ 3. Personal Notifications
#127
**FRD: Personal Notifications**
~43 tok
# **FRD: Personal Notifications** **Product:** Pixally CRM | **Version:** 1.0 | **Date:** December 11, 2025 | **Related FRDs:** Notification Center, Company Notifications
#128
**FRD: Personal Notifications** > **1\. Module Overview**
~7 tok
## **1\. Module Overview**
#129
**FRD: Personal Notifications** > **1\. Module Overview** > 1.1 Module Name
~11 tok
### 1.1 Module Name Personal Notifications
#130
**FRD: Personal Notifications** > **1\. Module Overview** > 1.2 Purpose
~147 tok
### 1.2 Purpose The Personal Notifications module enables individual users to customize their notification preferences based on their specific role and responsibilities within Pixally CRM. Each user role has access to a curated set of notification types relevant to their functions, and users can configure which notifications they wish to receive and through which delivery channels. Personal Notification settings allow users to override company-wide defaults established by Agency Owners and Admins, providing personalization while maintaining organizational consistency as a baseline.
#131
**FRD: Personal Notifications** > **1\. Module Overview** > 1.3 Business Goals
~184 tok
### 1.3 Business Goals * Allow individual users to tailor their notification experience according to their personal preferences and work style. * Reduce alert fatigue by enabling users to disable notifications they find irrelevant to their daily responsibilities. * Present only notification types that are relevant to each user's role, eliminating confusion and reducing settings clutter. * Support flexible multi-channel delivery with options for None, In-App, and Email that can be combined simultaneously. * Ensure initial user engagement by defaulting all notifications to enabled status for new users. * Maintain company alignment by inheriting company defaults as the baseline while allowing individual customization.
#132
**FRD: Personal Notifications** > **2\. User Roles & Permissions**
~9 tok
## **2\. User Roles & Permissions**
#133
**FRD: Personal Notifications** > **2\. User Roles & Permissions** > 2.1 Roles with Access to Personal Notifications
~197 tok
### 2.1 Roles with Access to Personal Notifications **Role** **Access Personal Notification Settings** **Configure Own Preferences** **Notification Categories Visible** Agency Owner Yes Yes Finance, Projects, Client Activity, Post-Production, News Admin Yes Yes Finance, Projects, Client Activity, Post-Production, News Project Manager Yes Yes Finance, Projects, Client Activity, Post-Production, News Normal User (Staff) Yes Yes Finance, Projects, Client Activity, Post-Production, News Editor Yes Yes Assignments, Feedback, Payments Contractor Yes Yes Projects, Tasks, Communication, Payments, Forms, Security Client No No N/A — Clients receive all notifications automatically Gawd Portal User Yes Yes User Activity, Billing, Account Status, Security
#134
**FRD: Personal Notifications** > **2\. User Roles & Permissions** > 2.2 Permission Details
~173 tok
### 2.2 Permission Details * All users except Clients can access their Personal Notification settings via Settings > Notifications. * Users can only modify their own notification preferences; they cannot view or modify other users' settings. * Each role sees only the notification types that are relevant to their specific function within the platform. * Clients receive all applicable notifications automatically without any ability to configure preferences. * Post-Production notifications are only visible to users whose agency has the Post-Production add-on subscription. * Contractor-related notifications are only visible to agencies with the Contractor Portal subscription.
#135
**FRD: Personal Notifications** > **3\. User Flow**
~532 tok
## **3\. User Flow** 3.1 The user logs into Pixally CRM and navigates to the Settings area from the main navigation menu. 3.2 The system displays the Settings page with various configuration options in the sidebar. 3.3 The user clicks on "Notifications" in the settings sidebar. 3.4 The system loads the Notification Settings page. 3.5 For Agency Owner or Admin users, the system displays two tabs: "Personal Notifications" (selected by default) and "Company Notifications". 3.6 For all other roles (Project Manager, Staff, Editor, Contractor), the system displays only the Personal Notifications content without any tab interface. 3.7 The system displays the user's notification settings organized into role-specific categories with expandable or scrollable sections. 3.8 Each category displays a header with an icon and the category name. 3.9 The user scrolls through the categories to view all available notification types for their role. 3.10 Each notification type displays its name, a brief description, and three channel options: None, In-App, and Email. 3.11 The user locates a notification type they wish to configure, such as "Invoice fully paid". 3.12 The user clicks on the In-App option to enable in-app notifications for this type. 3.13 The system immediately saves the preference and displays a brief visual confirmation. 3.14 The user clicks on the Email option to also enable email notifications for the same type. 3.15 The system saves the multi-channel selection, allowing both In-App and Email to be active simultaneously. 3.16 The user locates a notification type they wish to disable completely. 3.17 The user clicks on None for that notification type. 3.18 The system saves the preference, deselects both In-App and Email, and displays confirmation that the user will no longer receive this notification. 3.19 The user navigates away from the Personal Notifications page. 3.20 The system has auto-saved all changes without requiring an explicit save action. 3.21 The user returns to Personal Notifications later and sees all their previously configured preferences persisted correctly.
#136
**FRD: Personal Notifications** > **4\. Functional Logic**
~7 tok
## **4\. Functional Logic**
#137
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.1 Default Settings and Initialization
~239 tok
### 4.1 Default Settings and Initialization * When a new user account is created, all notification types applicable to that user's role shall be initialized with default settings. * The default delivery channel settings shall be both In-App and Email enabled for all notification types. * If the user's agency has Company Notification settings configured, the new user's personal settings shall inherit those company defaults instead of system defaults. * For notification types not configured at the company level, system defaults shall apply with all channels enabled. * When a new notification type is added to the platform, it shall default to enabled (In-App and Email) for all applicable users. * When a user's role changes, new notification types applicable to the new role shall appear with default enabled settings, and notification types no longer applicable shall be hidden but their preferences shall be preserved in the database.
#138
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.2 Delivery Channel Options
~204 tok
### 4.2 Delivery Channel Options * Each notification type shall display three channel options: None, In-App, and Email. * The In-App channel shall cause notifications to appear in the Notification Center accessible via the bell icon. * The Email channel shall cause notifications to be sent to the user's registered email address. * In-App and Email channels shall function as independent options that can be enabled simultaneously for multi-channel delivery. * Selecting None shall disable the notification entirely, preventing delivery through any channel. * When the user selects None, both In-App and Email shall be visually deselected. * SMS is not available as a delivery channel in Personal Notifications; it is only configurable at the Company Notifications level for specific reminder types.
#139
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.3 Normal Subscriber Notifications (Agency Owner, Admin, Project Manager, Staff)
~21 tok
### 4.3 Normal Subscriber Notifications (Agency Owner, Admin, Project Manager, Staff)
#140
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.3 Normal Subscriber Notifications (Agency Owner, Admin, Project Manager, Staff) > **4.3.1 Finance & Invoicing Category**
~350 tok
#### **4.3.1 Finance & Invoicing Category** * When a client completes full payment on an invoice, the system shall trigger the "Invoice fully paid" notification and deliver it to the Agency Owner, Admin, and Project Manager associated with that project via their personally configured channels. * When a client makes a partial payment on an invoice, the system shall trigger the "Invoice payment made" notification and deliver it to the Agency Owner, Admin, and Project Manager associated with that project. * When an invoice due date passes without full payment, the system shall trigger the "Invoice is overdue" notification and deliver it to the Agency Owner, Admin, and Project Manager associated with that project. * When a client's payment attempt fails due to declined card or insufficient funds, the system shall trigger the "Invoice payment failed" notification and deliver it to the Agency Owner, Admin, and Project Manager associated with that project. * When any payment is successfully received and processed, the system shall trigger the "Payment received" notification and deliver it to the Agency Owner, Admin, and Project Manager associated with that project. * When a contractor submits a payment request for completed work, the system shall trigger the "Payment request received from contractor" notification and deliver it to the Agency Owner and Admin of the agency.
#141
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.3 Normal Subscriber Notifications (Agency Owner, Admin, Project Manager, Staff) > **4.3.2 Projects and Events Category**
~732 tok
#### **4.3.2 Projects and Events Category** * When a client completes and submits a questionnaire, the system shall trigger the "Questionnaire is filled out" notification and deliver it to the Agency Owner, Admin, and Project Manager associated with that project. * When a prospective client submits a lead form on the website, the system shall trigger the "Lead form submitted" notification and deliver it to the Agency Owner, Admin, and designated lead handler. * When a client opens and views a sent proposal, the system shall trigger the "Client views a proposal" notification and deliver it to the user who sent the proposal, as well as the Agency Owner. * When a client signs a booking proposal, the system shall trigger the "Booking proposal signed" notification and deliver it to the Agency Owner, Admin, and Project Manager associated with that project. * When a booking proposal reaches its expiration date without being signed, the system shall trigger the "Booking proposal expires" notification and deliver it to the Agency Owner, Admin, and Project Manager as a warning. * When a client signs a contract, the system shall trigger the "Contract is signed" notification and deliver it to the Agency Owner, Admin, and Project Manager associated with that project. * When a user uploads a file to a project, the system shall trigger the "File uploaded" notification and deliver it to all team members associated with that project. * When a client uploads a document to their project portal, the system shall trigger the "Client uploads a document" notification and deliver it to the Agency Owner, Admin, and Project Manager associated with that project. * When the system date reaches 5 days before a scheduled event, the system shall trigger the "Upcoming event reminder" notification and deliver it to the Agency Owner, Admin, Project Manager, and assigned staff for that event. * When a new email is received in the Pixally email system for a project, the system shall trigger the "New email received" notification and deliver it to the project owner and team members associated with that project. * When a task passes its due date without being marked complete, the system shall trigger the "Overdue tasks" notification and deliver it to the task assignee and the user who created the task. * When a task deadline is approaching based on configured reminder timing, the system shall trigger the "Task reminders" notification and deliver it to the task assignee. * When there is activity in the referral program such as a new referral submission or conversion, the system shall trigger the "Referral program updates" notification and deliver it to the Agency Owner and Admin. * When a project or event is canceled, the system shall trigger the "Project/Event canceled" notification and deliver it to all team members, assigned contractors, and the client associated with that project.
#142
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.3 Normal Subscriber Notifications (Agency Owner, Admin, Project Manager, Staff) > **4.3.3 Client & Contractor Activity Category**
~298 tok
#### **4.3.3 Client & Contractor Activity Category** * When a client submits any form or questionnaire, the system shall trigger the "Client submitted a form or questionnaire" notification and deliver it to the project owner and team members. * When a client signs any contract document, the system shall trigger the "Client signed a contract" notification and deliver it to the project owner and team members. * When a client uploads files to their project portal, the system shall trigger the "Client uploaded files" notification and deliver it to the project owner and team members. * When a client sends a message or replies to a conversation, the system shall trigger the "Client sent a message or replied" notification and deliver it to the recipient of the message. * When a contractor or team member marks a task as completed, the system shall trigger the "Contractor/Team Member marked task as completed" notification and deliver it to the user who created the task and the project owner. * When a contractor uploads deliverables to a project, the system shall trigger the "Contractor adds deliverables" notification and deliver it to the project owner and Agency Owner.
#143
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.3 Normal Subscriber Notifications (Agency Owner, Admin, Project Manager, Staff) > **4.3.4 Post-Production Category (Subscription Required)**
~298 tok
#### **4.3.4 Post-Production Category (Subscription Required)** * When a project's post-production status changes in the workflow, the system shall trigger the "Project moves to a new status" notification and deliver it to all team members attached to that post-production job. * When edited files are delivered to the client, the system shall trigger the "Job was delivered to the client" notification and deliver it to the project owner and Agency Owner. * When a post-production job passes its deadline without completion, the system shall trigger the "Job is overdue" notification and deliver it to the assigned editor and project owner. * When a user is mentioned using @ in a post-production comment or note, the system shall trigger the "Editor mentioned you" notification and deliver it specifically to the mentioned user. * When a client or team member leaves feedback on a file, the system shall trigger the "Feedback on a file" notification and deliver it to the assigned editor and project owner. * When a new message is posted on a post-production job, the system shall trigger the "New message on job" notification and deliver it to all users attached to that job.
#144
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.3 Normal Subscriber Notifications (Agency Owner, Admin, Project Manager, Staff) > **4.3.5 Pixally News and Updates Category**
~62 tok
#### **4.3.5 Pixally News and Updates Category** * When Pixally releases new features, product improvements, or platform updates, the system shall trigger the "Product updates" notification and deliver it to all active users across the platform.
#145
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.4 Editor Role Notifications
~8 tok
### 4.4 Editor Role Notifications
#146
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.4 Editor Role Notifications > **4.4.1 Assignments & Tasks Category**
~241 tok
#### **4.4.1 Assignments & Tasks Category** * When an editor is assigned to a new post-production editing task, the system shall trigger the "Assigned to a new editing task" notification and deliver it to the assigned editor. * When an editor is removed from a task they were previously assigned to, the system shall trigger the "Removed from a task" notification and deliver it to the removed editor. * When a task assigned to an editor is approaching its due date, the system shall trigger the "Task due soon" notification and deliver it to the assigned editor. * When a task assigned to an editor passes its due date without completion, the system shall trigger the "Task is overdue" notification and deliver it to the assigned editor. * When a job status changes to "Edit Complete" and the editor is the Lead Editor, the system shall trigger the "Job moved to Edit Complete" notification and deliver it only to the Lead Editor assigned to that job.
#147
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.4 Editor Role Notifications > **4.4.2 Feedback & Collaboration Category**
~198 tok
#### **4.4.2 Feedback & Collaboration Category** * When a new message is posted on a post-production job the editor is attached to, the system shall trigger the "New message on job" notification and deliver it to the attached editor. * When an item the editor is working on moves to "Revision Needed" status, the system shall trigger the "Item moved to Revision Needed" notification and deliver it to the editor attached to that item. * When someone mentions the editor using @ in a comment or internal note, the system shall trigger the "Mentioned in comment" notification and deliver it to the mentioned editor. * When a teammate replies to the editor's comment or question, the system shall trigger the "Reply to your comment" notification and deliver it to the original commenter.
#148
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.4 Editor Role Notifications > **4.4.3 Payments Category**
~51 tok
#### **4.4.3 Payments Category** * When a job the editor worked on is marked as paid, the system shall trigger the "Job marked as paid" notification and deliver it to the editor who completed that job.
#149
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.5 Contractor Role Notifications
~9 tok
### 4.5 Contractor Role Notifications
#150
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.5 Contractor Role Notifications > **4.5.1 Project Assignment & Updates Category**
~306 tok
#### **4.5.1 Project Assignment & Updates Category** * When a contractor is assigned to a new project, the system shall trigger the "Assigned to a new project" notification and deliver it to the assigned contractor. * When a contractor is removed from a project they were assigned to, the system shall trigger the "Removed from a project" notification and deliver it to the removed contractor. * When project details such as date, time, location, or services are updated after contractor assignment, the system shall trigger the "Project details updated" notification and deliver it to all contractors assigned to that project. * When the event date or time is changed for a project, the system shall trigger the "Event date/time changed" notification and deliver it to all contractors assigned to that project. * When a project the contractor is assigned to is canceled, the system shall trigger the "Project canceled" notification and deliver it to all contractors who were assigned to that project. * When the system date reaches 6 days before and 1 day before an assigned event, the system shall trigger the "Upcoming assignment reminder" notification and deliver it to the contractor assigned to that event.
#151
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.5 Contractor Role Notifications > **4.5.2 Deliverables & Tasks Category**
~184 tok
#### **4.5.2 Deliverables & Tasks Category** * When a new task is assigned to a contractor, the system shall trigger the "New task assigned" notification and deliver it to the assigned contractor. * When a task deadline is 3 days away, the system shall trigger the "Task deadline approaching" notification and deliver it to the contractor assigned to that task. * When a task assigned to the contractor passes its due date, the system shall trigger the "Task marked as overdue" notification and deliver it to the assigned contractor. * When another collaborator completes a task on a shared project, the system shall trigger the "Task completed by collaborator" notification and deliver it to other contractors on that project.
#152
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.5 Contractor Role Notifications > **4.5.3 Communication & Feedback Category**
~160 tok
#### **4.5.3 Communication & Feedback Category** * When a client or project owner sends a message to the contractor, the system shall trigger the "New message from client or owner" notification and deliver it to the contractor. * When someone mentions the contractor using @ in a project comment, the system shall trigger the "Mentioned in project comment" notification and deliver it to the mentioned contractor. * When a client or agency provides feedback on the contractor's delivered work, the system shall trigger the "Feedback submitted on delivered work" notification and deliver it to the contractor who completed that work.
#153
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.5 Contractor Role Notifications > **4.5.4 Payments Category**
~222 tok
#### **4.5.4 Payments Category** * When a contractor submits a payment request and it is successfully recorded, the system shall trigger the "Payment request submitted successfully" notification and deliver it to the contractor who submitted the request. * When the agency approves the contractor's payment request, the system shall trigger the "Payment approved" notification and deliver it to the contractor. * When payment is processed and sent to the contractor, the system shall trigger the "Payment sent" notification and deliver it to the contractor. * When a payment to the contractor fails due to banking issues, the system shall trigger the "Payment failed" notification and deliver it to the contractor. * When a payment to the contractor is delayed from the expected date, the system shall trigger the "Payment delayed" notification and deliver it to the contractor.
#154
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.5 Contractor Role Notifications > **4.5.5 Forms, Contracts, and Docs Category**
~246 tok
#### **4.5.5 Forms, Contracts, and Docs Category** * When an agency sends a contract to the contractor for signing, the system shall trigger the "Contract sent" notification and deliver it to the contractor. * When the contractor successfully signs a contract, the system shall trigger the "Contract signed successfully" notification and deliver it to the contractor as confirmation. * When a contractor has an unsigned IC agreement and one week has passed since sending, the system shall trigger the "Contract still unsigned reminder" notification and deliver it to the contractor weekly until signed. * When a questionnaire such as pre-shoot information form is assigned to the contractor, the system shall trigger the "Questionnaire assigned" notification and deliver it to the contractor. * When a questionnaire assigned to the contractor is approaching its due date, the system shall trigger the "Questionnaire due soon" notification and deliver it to the contractor.
#155
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.5 Contractor Role Notifications > **4.5.6 Security & Account Integrity Category**
~186 tok
#### **4.5.6 Security & Account Integrity Category** * When a new contractor account is created, the system shall trigger the "Account created" notification and deliver it to the new contractor as a welcome message. * When the contractor logs in from a new or unrecognized device, the system shall trigger the "Login from new device" notification and deliver it to the contractor as a security alert. * When a password reset is requested for the contractor's account, the system shall trigger the "Password reset requested" notification and deliver it to the contractor. * When an admin updates the contractor's profile information, the system shall trigger the "Profile updated by admin" notification and deliver it to the contractor.
#156
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.5 Contractor Role Notifications > **4.5.7 Additional Contractor Notifications (from MOM)**
~271 tok
#### **4.5.7 Additional Contractor Notifications (from MOM)** * Every January, the system shall trigger the "W9 Annual Reminder" notification and deliver it via email to all active contractors, reminding them to update their W9 if personal details have changed. * When a contractor's cumulative payments exceed $600 in a calendar year, the system shall trigger the "$600 Payment Threshold Alert" notification and deliver it to the contractor informing them of IRS reporting requirements. * When a contractor's IC agreement remains unsigned after initial sending, the system shall trigger the "IC Agreement Signing Reminder" notification weekly until the agreement is signed. * When auto-calculated hours or coverage changes affect the contractor's pay rate, the system shall trigger the "Pay Rate Change Alert" notification as an in-app popup to the contractor. * When a contractor changes their booking window and it conflicts with already scheduled jobs, the system shall trigger the "Booking Window Change Warning" notification as an in-app popup to warn the contractor.
#157
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.6 Client Role Notifications (Non-Configurable)
~608 tok
### 4.6 Client Role Notifications (Non-Configurable) * Clients do not have access to Personal Notification settings and cannot configure their preferences. * Clients receive all applicable notifications automatically based on project activity and company settings. * The delivery channels for client notifications are determined by the system and company configuration, not by client preference. * When a proposal is sent to the client, the system shall trigger the "Proposal received" notification and deliver it via Email and In-App to the client. * When a contract is ready for the client to sign, the system shall trigger the "Contract ready for signing" notification and deliver it via Email and In-App to the client. * When an invoice is generated for the client, the system shall trigger the "Invoice generated" notification and deliver it via Email and In-App to the client. * Payment reminders for upcoming, due, and overdue payments shall be triggered according to the Company Notification settings and delivered to the client via the channels configured by the agency. * When the client's payment is successfully processed, the system shall trigger the "Payment confirmation" notification and deliver it via Email and In-App to the client. * When the client's payment attempt fails, the system shall trigger the "Payment failed" notification and deliver it via Email and In-App to the client. * When a questionnaire is assigned to the client, the system shall trigger the "Questionnaire assigned" notification and deliver it via Email and In-App to the client. * When event details such as date, time, or location are updated, the system shall trigger the "Event details updated" notification and deliver it via Email and In-App to the client. * When an event is canceled, the system shall trigger the "Event canceled" notification and deliver it via Email and In-App to the client. * When files or deliverables are made available to the client, the system shall trigger the "File available" notification and deliver it via Email and In-App to the client. * When the agency sends a message to the client, the system shall trigger the "Message received" notification and deliver it via Email and In-App to the client. * When the payment schedule is modified after contract signing, the system shall trigger the "Payment schedule updated" notification and deliver it via Email to the client.
#158
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.7 Gawd Portal User Notifications
~10 tok
### 4.7 Gawd Portal User Notifications
#159
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.7 Gawd Portal User Notifications > **4.7.1 New User Activity Category**
~101 tok
#### **4.7.1 New User Activity Category** * When a new user signs up for a free trial on the Pixally platform, the system shall trigger the "Free trial user signed up" notification and deliver it to Gawd Portal administrators. * When a free trial user converts to a paid subscription, the system shall trigger the "Free trial user converted" notification and deliver it to Gawd Portal administrators.
#160
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.7 Gawd Portal User Notifications > **4.7.2 Payments & Billing Category**
~185 tok
#### **4.7.2 Payments & Billing Category** * When a subscription payment is successfully processed, the system shall trigger the "Subscription payment successful" notification and deliver it to Gawd Portal administrators. * When a subscription payment fails, the system shall trigger the "Subscription payment failed" notification and deliver it to Gawd Portal administrators. * When a user's saved credit card is approaching its expiration date, the system shall trigger the "Credit card expiring soon" notification and deliver it to Gawd Portal administrators. * When a new subscription receipt is generated, the system shall trigger the "Subscription receipt available" notification and deliver it to Gawd Portal administrators.
#161
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.7 Gawd Portal User Notifications > **4.7.3 Account Status & Plan Changes Category**
~135 tok
#### **4.7.3 Account Status & Plan Changes Category** * When an agency account is frozen due to non-payment, the system shall trigger the "Account frozen" notification and deliver it to Gawd Portal administrators. * When a user cancels their subscription, the system shall trigger the "Subscription canceled" notification and deliver it to Gawd Portal administrators. * When a subscription plan is changed or renewed, the system shall trigger the "Subscription plan changed" notification and deliver it to Gawd Portal administrators.
#162
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.7 Gawd Portal User Notifications > **4.7.4 Security & Account Integrity Category**
~97 tok
#### **4.7.4 Security & Account Integrity Category** * When suspicious login activity is detected on any account, the system shall trigger the "Suspicious login activity" notification and deliver it to Gawd Portal administrators. * When any project is deleted from the platform, the system shall trigger the "Project deleted" notification and deliver it to Gawd Portal administrators.
#163
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.8 Additional Notifications from Client MOM
~12 tok
### 4.8 Additional Notifications from Client MOM
#164
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.8 Additional Notifications from Client MOM > **4.8.1 Normal Subscriber Additional Notifications**
~318 tok
#### **4.8.1 Normal Subscriber Additional Notifications** * When a new lead's date conflicts with an existing booking or lead, the system shall trigger the "Lead conflict warning" notification as an in-app popup and email to the Agency Owner and Admin. * When a project is booked but contractor spots remain unfilled, the system shall trigger the "Unassigned contractor alert" notification and deliver it to the Agency Owner and Admin. * Weekly, the system shall generate a "Weekly summary - Overdue jobs needing assignment" digest notification containing all jobs that need lead shooter or second shooter assignment, and deliver it via email to the Agency Owner. * Weekly, the system shall generate a "Weekly summary - Unassigned second shooters" digest notification containing upcoming jobs without a second shooter assigned, and deliver it via email to the Agency Owner. * When a job needs a second shooter assigned, the system shall trigger a "Second shooter reminder to Lead Shooter" notification and deliver it to the Lead Shooter assigned to that job. * When contractors have pending invitations that haven't been accepted, the system shall trigger the "Pending contractor invitation reminder" notification and deliver it to the Agency Owner and Admin.
#165
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.8 Additional Notifications from Client MOM > **4.8.2 All Roles Additional Notification**
~70 tok
#### **4.8.2 All Roles Additional Notification** * When the agency owner's payment fails and the account is suspended, the system shall trigger the "Account suspended warning" notification as an in-app popup to all users of that agency, informing them of the access restriction.
#166
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.9 Relationship with Company Notifications
~304 tok
### 4.9 Relationship with Company Notifications * When determining which notification setting to apply, the system shall use the following priority hierarchy: Personal Notification settings take highest priority if the user has explicitly customized them, Company Notification settings apply if the user has not customized that specific preference, and System Defaults apply if neither personal nor company settings exist. * A user is considered to have "customized" a setting when they have explicitly interacted with and changed that setting from its inherited default. * Company Notification setting changes shall apply immediately to users who have not customized that specific personal notification setting. * Company Notification setting changes shall not overwrite or modify existing personal customizations that users have already made. * When a new user joins an agency, their personal notification settings shall be initialized with the current company default values for all applicable notification types. * The Personal Notification settings UI shall display the effective setting for each notification type without indicating whether it came from personal customization or company default.
#167
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.10 Subscription-Based Feature Restrictions
~271 tok
### 4.10 Subscription-Based Feature Restrictions * Notification categories requiring specific subscription add-ons shall be completely hidden from users whose agency does not have the required subscription. * Post-Production category notifications shall only be visible to users in agencies with the Post-Production add-on subscription. * Referral Program notification shall only be visible to users in agencies with the Referral feature enabled. * Contractor-related notifications within Normal Subscriber settings shall only be visible to agencies with the Contractor Portal add-on subscription. * When a subscription lapses, the affected notification categories shall become hidden from the Personal Notification settings UI. * User preferences for subscription-gated notifications shall be preserved in the database even when the subscription lapses, and shall be restored when the subscription is renewed. * When a subscription is added, the previously hidden notification categories shall appear with either the preserved preferences or default enabled settings.
#168
**FRD: Personal Notifications** > **4\. Functional Logic** > 4.11 Settings Auto-Save Behavior
~179 tok
### 4.11 Settings Auto-Save Behavior * All Personal Notification preference changes shall be automatically saved immediately when the user interacts with any channel toggle. * No explicit "Save" button shall be required or displayed for saving Personal Notification settings. * When a setting is successfully saved, a brief visual indicator such as a checkmark animation or subtle confirmation shall appear. * If a save operation fails due to network or server issues, the UI shall revert the toggle to its previous state and display an error message. * The is\_customized flag shall be set to true for a notification setting when the user first explicitly changes it from its default or inherited value.
#169
**FRD: Personal Notifications** > **5\. Field Details & Validations**
~230 tok
## **5\. Field Details & Validations** **Field Name** **Field Type** **Validation Rules** setting\_id UUID System-generated unique identifier; primary key user\_id UUID Required; must reference an existing user; foreign key; indexed for queries agency\_id UUID Required; must reference an existing agency; foreign key notification\_type String Required; maximum 100 characters; must match a predefined notification type identifier in\_app\_enabled Boolean Required; default: true; determines if notification appears in Notification Center email\_enabled Boolean Required; default: true; determines if notification is sent via email is\_customized Boolean Required; default: false; set to true when user explicitly changes the setting created\_at DateTime System-generated timestamp when setting record was created updated\_at DateTime System-updated timestamp when setting was last modified
#170
**FRD: Personal Notifications** > **6\. Success Message Handling**
~351 tok
## **6\. Success Message Handling** **Operation** **Success Message** **Trigger Condition** **Post-Success Action** Enable In-App channel "Notification preferences updated" User clicks In-App option to enable Save setting to database; display brief checkmark animation Enable Email channel "Notification preferences updated" User clicks Email option to enable Save setting to database; display brief checkmark animation Enable both channels "Notification preferences updated" User enables both In-App and Email for a notification Save multi-channel selection; display confirmation Disable In-App channel "Notification preferences updated" User clicks In-App option to disable Save setting to database; update toggle visual state Disable Email channel "Notification preferences updated" User clicks Email option to disable Save setting to database; update toggle visual state Select None "You will no longer receive this notification" User clicks None option for a notification type Save setting; deselect both channels; display confirmation Reset to defaults "Notification preferences reset to defaults" User clicks reset option if available Restore all settings to In-App + Email enabled; apply company defaults Any setting auto-saved Brief checkmark animation (no text message) Any toggle change saved successfully Visual feedback without modal or toast interruption
#171
**FRD: Personal Notifications** > **7\. Error Message Handling**
~445 tok
## **7\. Error Message Handling** **Error Scenario** **Error Message** **Trigger Condition** **User Action Required** **System Response** Failed to load settings "Unable to load notification preferences. Please try again." API request to fetch personal settings fails Refresh page or click retry button Display error with retry button Failed to save preference "Unable to save preference. Please try again." API request to save setting change fails Try making the change again Revert toggle to previous state; display error toast Network connectivity lost "You appear to be offline. Changes cannot be saved." System detects no network connectivity Restore network connection Disable all toggles; show offline indicator Session expired "Your session has expired. Please log in again." Authentication token expired during interaction Log in again Redirect to login page Invalid notification type "This notification type is not available." Corrupted or invalid notification type in database Contact support Log error; hide invalid notification type Role mismatch "This notification is not available for your role." User's role changed and notification no longer applicable Refresh page Hide inapplicable notification types Subscription required "This notification requires \[Feature Name\] subscription." User tries to access gated notification without subscription Upgrade subscription Show upgrade prompt if applicable; hide category User record not found "Unable to load your preferences. Please try again." User record issue in database Contact support Display error; prevent any changes Reset preferences failed "Unable to reset preferences. Please try again." Reset operation fails Try again Keep current settings; display error
#172
**FRD: Personal Notifications** > **8\. Edge Cases**
~702 tok
## **8\. Edge Cases** **Edge Case Scenario** **Description** **Expected System Behavior** New user first login User logs in for the first time after account creation All notifications default to enabled (In-App + Email); inherit company defaults if configured User with no customizations User has never changed any notification settings Company defaults or system defaults apply to all notification types User disables all notifications User selects None for every notification type System allows this; user receives no notifications at all Role upgrade to Admin Staff user is promoted to Admin role Additional notification types appear for new role; new types default to enabled Role downgrade from Admin Admin is demoted to Staff role Some notification types hidden; preferences preserved in database for potential future restoration Subscription added Agency adds Post-Production subscription Post-Production notification category appears with default enabled settings Subscription removed Agency removes Post-Production subscription Post-Production category hidden; existing preferences preserved in database Company setting changes Admin changes a company notification default Users with personal customizations unaffected; users without customizations receive new default Rapid toggle clicks User clicks multiple toggles in quick succession Each click queued and processed sequentially; final state reflects all changes Page refresh during save User refreshes page while save is in progress In-progress save may or may not complete; page shows last confirmed saved state Multiple device usage User changes settings on phone while desktop is open Last save wins; no real-time cross-device synchronization Notification type deprecated A notification type is removed from the platform Type hidden from UI; existing preference data archived New notification type added Platform adds a new notification type Type appears for applicable roles with default enabled settings User account reactivated Deactivated user account is reactivated Previous preferences preserved and restored Contractor with multiple agencies Contractor works with multiple agencies Preferences are global to the user, not per-agency Invalid saved preference Database contains invalid value for a setting System defaults to enabled; error logged for investigation Very long notification name Notification name exceeds display width Name truncated with ellipsis; full name shown in tooltip on hover Keyboard navigation User navigates settings using only keyboard All toggles accessible via Tab key; proper focus management Large number of notification types User has 50+ notification types across categories Categories scrollable or collapsible; no pagination within categories
#173
**FRD: Personal Notifications** > **9\. Acceptance Criteria**
~8 tok
## **9\. Acceptance Criteria**
#174
**FRD: Personal Notifications** > **9\. Acceptance Criteria** > 9.1 Access and Display
~142 tok
### 9.1 Access and Display * All users except Clients must be able to access Personal Notification settings via Settings > Notifications. * Agency Owner and Admin users must see both "Personal Notifications" and "Company Notifications" tabs. * All other roles (PM, Staff, Editor, Contractor) must see only Personal Notifications without tab interface. * Notifications must be organized into role-appropriate categories. * Each category must display a header with icon and category name. * Categories must be scrollable or collapsible for easy navigation.
#175
**FRD: Personal Notifications** > **9\. Acceptance Criteria** > 9.2 Channel Selection
~114 tok
### 9.2 Channel Selection * None, In-App, and Email options must be displayed for each notification type. * In-App and Email must be selectable simultaneously for multi-channel delivery. * Selecting None must deselect both In-App and Email. * Selected options must be visually distinct from unselected options. * All changes must auto-save without requiring an explicit save button. * Visual confirmation must appear after each successful save.
#176
**FRD: Personal Notifications** > **9\. Acceptance Criteria** > 9.3 Default Behavior
~59 tok
### 9.3 Default Behavior * New users must have all notifications enabled by default (In-App + Email). * Company defaults must be inherited by new users where applicable. * System defaults must apply when no company setting exists.
#177
**FRD: Personal Notifications** > **9\. Acceptance Criteria** > 9.4 Normal Subscriber Notifications
~131 tok
### 9.4 Normal Subscriber Notifications * Finance & Invoicing category must display all 6 notification types. * Projects and Events category must display all 14 notification types. * Client & Contractor Activity category must display all 6 notification types. * Post-Production category must display all 6 notification types when subscription is active. * Pixally News and Updates must display the Product updates notification. * All notification types must be configurable with None, In-App, and Email options.
#178
**FRD: Personal Notifications** > **9\. Acceptance Criteria** > 9.5 Editor Notifications
~81 tok
### 9.5 Editor Notifications * Assignments & Tasks category must display all 5 notification types. * Feedback & Collaboration category must display all 4 notification types. * Payments category must display the Job marked as paid notification. * Editors must not see Finance, Projects, or Client Activity categories.
#179
**FRD: Personal Notifications** > **9\. Acceptance Criteria** > 9.6 Contractor Notifications
~121 tok
### 9.6 Contractor Notifications * Project Assignment & Updates category must display all 6 notification types. * Deliverables & Tasks category must display all 4 notification types. * Communication & Feedback category must display all 3 notification types. * Payments category must display all 5 notification types. * Forms, Contracts, and Docs category must display all 5 notification types. * Security & Account Integrity category must display all 4 notification types.
#180
**FRD: Personal Notifications** > **9\. Acceptance Criteria** > 9.7 Client Notifications
~55 tok
### 9.7 Client Notifications * Clients must not have access to notification settings. * Clients must receive all applicable notifications automatically. * Client notification delivery must follow company settings.
#181
**FRD: Personal Notifications** > **9\. Acceptance Criteria** > 9.8 Gawd Portal Notifications
~85 tok
### 9.8 Gawd Portal Notifications * New User Activity category must display all 2 notification types. * Payments & Billing category must display all 4 notification types. * Account Status & Plan Changes category must display all 3 notification types. * Security & Account Integrity category must display all 2 notification types.
#182
**FRD: Personal Notifications** > **9\. Acceptance Criteria** > 9.9 Override Behavior
~77 tok
### 9.9 Override Behavior * Personal customizations must take precedence over company defaults. * Users without customizations must receive company defaults. * Company setting changes must not overwrite existing personal customizations. * New users must inherit company defaults on account creation.
#183
**FRD: Personal Notifications** > **9\. Acceptance Criteria** > 9.10 Subscription Gating
~85 tok
### 9.10 Subscription Gating * Post-Production notifications must be hidden for agencies without Post-Production subscription. * Contractor-related notifications must be hidden without Contractor Portal subscription. * Gated features must be hidden rather than disabled. * Re-subscription must restore previously saved preferences.
#184
**FRD: Personal Notifications** > **9\. Acceptance Criteria** > 9.11 Error Handling
~79 tok
### 9.11 Error Handling * Failed saves must show error message and revert UI to previous state. * Network offline must disable editing and show warning message. * Role changes must update visible notification types appropriately. * Subscription changes must update visible notification types appropriately.
#185
**FRD: Personal Notifications** > **10\. Manual Test Cases**
~86 tok
## **10\. Manual Test Cases** The complete manual test cases for the Personal Notifications module are provided in a separate Excel file. **Test Case Document:** [TestCases-Personal-Notifications.xlsx](https://docs.google.com/spreadsheets/d/1UCwiRx-JyQbP4uSQE03V34CjRwfpD1J5/edit?usp=drive_link&ouid=105170312247554220827&rtpof=true&sd=true)
#186
**FRD: Personal Notifications** > **11\. Dependencies**
~532 tok
## **11\. Dependencies** **Dependency Type** **Dependency Name** **Description** **Impact if Unavailable** Internal Module User Management Provides user identity, role information, and authentication Cannot determine user role or applicable notification types Internal Module Company Notifications Provides company default settings for inheritance Personal settings work; users receive system defaults instead Internal Module Notification Center Displays In-App notifications based on personal settings Settings save but In-App notifications may not display Internal Module Notification Service Backend service that applies settings when delivering notifications Settings save but notification delivery ignores preferences Internal Module Subscription Management Provides subscription tier for feature gating Cannot properly gate notification categories Internal Module Projects Module Provides project data for project-related notification triggers Project notifications will not trigger Internal Module Finance Module Provides invoice and payment data for finance notification triggers Finance notifications will not trigger Internal Module Post-Production Module Provides job and task data for editor notification triggers Editor notifications will not trigger Internal Module Contractor Portal Provides contractor data for contractor notification triggers Contractor notifications will not trigger Internal Module Lead Management Provides lead data for lead notification triggers Lead notifications will not trigger Internal Module Tasks Module Provides task data for task notification triggers Task notifications will not trigger External Service Email Service (SendGrid/SES) Delivers email notifications based on Email channel setting Email channel delivery fails Infrastructure Database Stores personal notification settings Complete module failure Infrastructure Cache (Redis) Caches settings for performance optimization Slower settings retrieval API Personal Settings API REST endpoints for settings CRUD operations Cannot load or save personal settings
#187
**FRD: Personal Notifications** > **12\. References**
~61 tok
## **12\. References** **Figma:** [https://www.figma.com/design/ej0kxwP45mDKmZCZfAJ5O8/Pixally?node-id=29836-120184&t=b6Vb2HmYBAZOvvUn-0](https://www.figma.com/design/ej0kxwP45mDKmZCZfAJ5O8/Pixally?node-id=29836-120184&t=b6Vb2HmYBAZOvvUn-0)