Reviewing Notification Delivery Data in MongoDB

Purpose

This runbook is used to review notification data in MongoDB and determine whether a user was correctly included in a project notification workflow.

The goal of the review is to trace the full notification path from the configured project rule, through group membership, to the generated in-app notification, and finally to the email notification. This allows Product Support to confirm whether a user should have been notified, whether an in-app notification was generated for them, and whether an email notification was also produced.

Overview of How Notifications Work

Notifications on the platform are driven by project rules.

A rule is configured on a workspace to send notifications when a specific action occurs. When that rule is triggered, the system determines which users should receive the notification based on the user groups selected in the rule configuration.

The review process follows this logic:

1. A rule is configured on the workspace.
2. The rule references one or more groups that should receive a notification.
3. When the rule is triggered, the system checks whether a given user is a member of one of the groups attached to that rule.
4. If the user is in a valid target group, the system proceeds to generate notifications.
5. The system generates an in-app notification.
6. The system then generates an email notification using the in-app notification content.
7. If multiple in-app notifications are triggered within one minute, they may be collated into a single email notification.

Because of this, a complete review must validate not just whether an email exists, but whether the user should have been eligible in the first place, whether the in-app notification was generated, and whether the email record correctly references that notification activity.

Core Review Principle

When investigating whether a user was correctly notified, the review should always move through the data in the following order:

Workspace -> Rule -> Group -> User -> In-App Notification -> Email Notification

This order is important because email records alone do not prove whether a user should have received a notification. Eligibility is determined earlier in the chain by the workspace rule and the user’s group membership.

Database and Collection Relationships

1. Workspace Database

Database name: region-clientname
Collection: workspace

This database is used to identify the workspace being reviewed.

It is primarily used to:

• locate the workspace by name
• obtain the workspace ID
• confirm you are reviewing the correct project

The workspace ID will be a key reference point when linking the notification activity back to the correct project.

2. Rules Database

Database name: region-clientname-rules

This database contains the rule and notification records for the workspace.

Collections

rule
Contains the project-specific notification rules and associated configuration.

Used to determine:

• which rule was configured
• what event or action triggered the rule
• which groups were selected to receive notifications

wsnotification
Contains the generated in-app notifications.

Used to determine:

• whether an in-app notification was created when the rule triggered
• which users were targeted by that notification
• the content generated for the notification

These records are created per rule trigger and contain the user targeting information needed for review.

emailsummary
Contains the generated email notifications.

Used to determine:

• whether an email notification was generated from the in-app notification
• which in-app notification ID the email relates to
• whether multiple in-app notifications were collated into a single email

This collection is the email-side record of the notification flow.

3. User Management Database

Database name: region-clientname-user-management

This database is used to validate the people and groups involved in the notification workflow.

Collections

User
Contains user information, including the user ID.

Used to:

• identify the user being reviewed
• retrieve the correct user ID for matching against group membership and notification records
• confirm the correct account is being investigated

WorkspaceGroup
Contains group information, including group IDs and the users assigned to each group.

Used to determine:

• which groups exist on the workspace
• whether the user was a member of the group(s) referenced by the rule
• whether the user should have been eligible for notification at the point the rule triggered

End-to-End Data Linkage

Step 1: Identify the workspace

Start in the workspace collection to locate the project by name and retrieve the workspace ID.

Step 2: Identify the relevant rule

Move to the rule collection in the -rules database and locate the rule configured for the action being reviewed.

This rule should show which group or groups were selected as recipients.

Step 3: Confirm group membership

Use the WorkspaceGroup collection in the -user-management database to identify the group IDs referenced by the rule and confirm whether the user was a member of those groups.

This is the first decision point in the review:

• If the user was not in one of the selected groups, they were not eligible for notification.
• If the user was in one of the selected groups, proceed to review generated notifications.

Step 4: Confirm in-app notification generation

Use the wsnotification collection to locate the in-app notification generated when the rule triggered.

This should show:

• the notification record itself
• the content generated
• the list of users who were intended recipients

This confirms whether the user was included in the generated in-app notification.

Step 5: Confirm email notification generation

Use the emailsummary collection to locate the email notification generated from the in-app notification.

The email record should reference the corresponding in-app notification ID.

This allows you to confirm whether:

• a matching email record exists for the in-app notification
• the notification was sent as an individual email, or
• the notification was collated with other in-app notifications into a single email within the one-minute window

Important Notification Behaviour

In-app notifications are generated first

The in-app notification is the primary generated notification record. It contains the content and the intended recipients.

Email notifications are generated from in-app notifications

The email notification uses the content from the in-app notification. This means the in-app notification is the parent record for the email-side review.

Email collation can affect one-to-one matching

If multiple in-app notifications are triggered within one minute, the system may combine them into a single email notification.

In these cases:

• there may not be a one-email-to-one-in-app-notification relationship
• a single emailsummary document may contain multiple in-app notification IDs
• absence of a standalone email record for one notification does not automatically mean the notification was missed

This behaviour must always be considered when reviewing email delivery.

Step-by-Step Data Identification

Step 1: Find the Workspace ID

Start in the following collection:

• Database: region-clientname
• Collection: workspace

Use the following Mongo Atlas filter:

{ "obj.name": RegExp("^$NAME ") }

Replace $NAME with the information provided by the client.

Example

If the client provided 34627, use:

{ "obj.name": RegExp("^34627 ") }

What this does

This filter checks for all workspaces where obj.name begins with the provided pattern.

What to capture

From the resulting workspace document, capture:

• bid = the workspace ID

Step 2: Find the Relevant Rule

Move to the following collection:

• Database: region-clientname-rules
• Collection: rule

Use the following Mongo Atlas filter:

{
  workspaceId: "$workspaceID",
  name: RegExp("$RuleName ")
}

Replace:

• $workspaceID with the workspace bid
• $RuleName with the rule naming pattern

Example

{
  workspaceId: "110123456",
  name: RegExp("New Submission from Resp P ")
}

What to capture

From the resulting rule document, capture:

• bid = the rule ID
• actions.notifyIds = list of workspace groups that should receive the notification

Step 3: Review the Rule Notification Targets

In the same rule document, review:

• actions.notifyIds

This contains the workspace group IDs that should receive notifications when the rule triggers.

Example

workspacegroup-13
workspacegroup-22

Why this matters

This is the source of truth for which groups are configured to receive notifications for the rule under review.

Reporting note

If the relevant group is currently not listed in notifyIds, note on the report:

“Group is not present in current notification rules, so no notification would be received.”

Step 4: Find the User ID

Move to the following collection:

• Database: region-clientname-user-management
• Collection: user

Use the following Mongo Atlas filter:

{ name: "$NAME" }

Replace $NAME with the full name shown in System Admin.

Example

{ name: "SMITH John" }

What to capture

From the resulting user document, capture:

• bid = the user ID

Example

user-27

Data Points You Should Have Before Moving On

Before reviewing notification outcomes, you should now have:

• Workspace ID from workspace.bid
• Rule ID from rule.bid
• Target Group IDs from rule.actions.notifyIds
• User ID from user.bid

Confirming Whether the User Should Have Received a Notification

This section determines whether the user was actually eligible to receive the notification before investigating generated records.

Step 5: Check the User’s Workspace Group Membership

Move to the following collection:

• Database: region-clientname-user-management
• Collection: WorkspaceGroup

Use the following Mongo Atlas filter:

{
  workspaceBid: "$WorkspaceID",
  memberBids: "$UserID"
}

Replace:

• $WorkspaceID with the workspace ID
• $UserID with the user ID

Example

{
  workspaceBid: "110123456",
  memberBids: "user-27"
}

What this does

This returns all workspace groups on that project where the specified user is a member.

What to review

From the results, review:

• bid = the workspace group ID

Compare the returned group IDs to the values in:

• rule.actions.notifyIds

Group Membership Decision Logic

Outcome 1: No results returned

If no results are returned, the user is not a member of any groups on that workspace.

Interpretation

The user would not have been eligible to receive the notification through the configured rule logic.

Suggested report note

“User is not present in the group that receives notifications, so no notification would be received.”

Outcome 2: User is in one or more groups, but none match notifyIds

If the user is a member of one or more workspace groups, but none of those group IDs appear in the rule’s actions.notifyIds, the user is not in a group targeted by the rule.

Interpretation

The user would not have been expected to receive the notification for this rule.

Suggested report note

“Group is not present in current notification rules, so no notification would be received.”

Outcome 3: User is in a group that is listed in notifyIds

If one of the returned workspace group IDs matches a value in rule.actions.notifyIds, the user was eligible to receive the notification.

Interpretation

Proceed to verify whether the in-app notification was generated.

Verifying the In-App Notification

Once group eligibility has been confirmed, the next step is to verify whether the in-app notification was generated for the user, on the workspace, for the correct rule.

Step 6: Search for the In-App Notification

Move to the following collection:

• Database: region-clientname-rules
• Collection: wsnotification

Use the following Mongo Atlas filter:

{
  access: "$userid",
  workspaceId: "$workspaceID",
  ruleId: "$ruleID"
}

Replace:

• $userid with the user ID
• $workspaceID with the workspace ID
• $ruleID with the rule ID

Example

{
  access: "user-27",
  workspaceId: "110123456",
  ruleId: "rule-2"
}

Sort order

Apply the following sort:

{ created: -1 }

This sorts the most recent notifications to the top.

Optional Date Filtering

If the client has provided a specific day or date range, you can additionally filter on created.

Example:

{
  "created": {
    "$gte": ISODate("2023-10-25T00:00:00Z"),
    "$lt": ISODate("2023-10-26T00:00:00Z")
  }
}

Use this when the user has many historical notifications or when the incident occurred on a known date.

What to Capture from wsnotification

If a result is found, capture:

• bid = the in-app notification ID, e.g. wsnotification-24
• created = the date/time the in-app notification was generated
• notificationText = the content used to generate the notification

Example notification ID

wsnotification-24

In-App Notification Decision Logic

Outcome 1: In-app notification found

If a wsnotification record is found for that user, workspace, and rule, then the user received an in-app notification.

Interpretation

Proceed to check the matching email summary record.

Outcome 2: No in-app notification found

If no matching wsnotification record is found, verify whether the user was added after the notification event would have occurred.

To do this, check the user creation date in:

• Database: region-clientname-user-management
• Collection: user

Review the user document’s creation timestamp and compare it to the expected notification timing or to nearby notification records for the same rule/workspace.

Interpretation

If the user was added to the platform after the notification would have been generated, they would not have been part of the group at the time the notification was created.

Suggested report note

“User was not part of the group at time of notification generation.”

Note: There is currently no group membership added timestamp available, so user creation date is the closest available reference point for this check.

Verifying the Email Notification

If an in-app notification was found, the next step is to determine whether an email notification was also generated from it.

Step 7: Search for the Email Summary Record

Move to the following collection:

• Database: region-clientname-rules
• Collection: emailsummary

Use the following Mongo Atlas filter:

{
  workspaceId: "$workspaceID",
  notificationBid: "$wsnotification-X"
}

Replace:

• $workspaceID with the workspace ID
• $wsnotification-X with the in-app notification bid

Example

{
  workspaceId: "110123456",
  notificationBid: "wsnotification-24"
}

What this does

This returns the email summary record or records generated from the identified in-app notification.

What to Review in emailsummary

If a record is present, review:

• the send date/time
• the notificationBid field contents

Interpretation of notificationBid

If notificationBid contains only one item, the email was sent as an individual email.

If notificationBid contains multiple items, for example:

wsnotification-27
wsnotification-28

then one collated email was sent containing multiple in-app notifications.

Email Summary Decision Logic

Outcome 1: Email summary record found

If an emailsummary record is present, email notification generation can be confirmed.

Interpretation

You can confirm:

• the date/time the email was sent
• whether the email was individual or collated

Suggested conclusion

In-app notification and email notification were both generated successfully.

Outcome 2: No email summary record found

If no matching emailsummary record is found, return to the wsnotification document and review:

• notificationText

If notificationText contains unresolved variables such as:

${ref:projectid}
${ref:documentlist:0:0:principalId}

the system will not generate an email.

Why this happens

The presence of unresolved variables suggests a malformed URL or malformed notification content. As a fallback, the system does not send the email if it would contain a malformed URL.

Suggested report note

“Malformed URL detected in notification text, so email was not sent as fallback. In-app notification was received.”

Logic for Reporting to Client

By the end of the review, Support should be able to classify the outcome into one of the following:

1. User not eligible due to no group membership

User is not present in the group that receives notifications, so no notification would be received.

2. User in group, but group not configured on the rule

Group is not present in current notification rules, so no notification would be received.

3. User eligible, but no in-app notification generated because user was added later

User was not part of the group at time of notification generation.

4. User eligible and in-app notification generated, but email suppressed due to malformed notification text

Malformed URL detected in notification text, so email was not sent as fallback. In-app notification was received.

5. User eligible, in-app notification generated, and email generated

User correctly received the notification workflow. Confirm whether the email was sent individually or as part of a collated summary.