After-Hours Notification Digest Workflow

This article explains how to eliminate the pattern of overnight notifications waking an operator one at a time. When CRM notifications arrive between the end of one business day and the start of the next, each one triggers a separate alert, interrupting the on-call operator repeatedly and forcing them to wake or check their phone multiple times per night.

This article is relevant to operations leads, CRM administrators, and engineers who manage notification workflows in systems where alerts are generated outside business hours. It covers the conceptual design, the CRM configuration needed, the workflow logic, and the common failure modes.

After reading, you should be able to implement a single-morning-digest pattern for any notification type that currently fires individually after hours.

Before implementing this pattern, confirm the following are in place:

• A CRM platform that supports custom objects and workflow automation on record creation (for example, a standard CRM with object-level triggers)
• A way to distinguish business hours from after-hours in the notification source (a timestamp field or schedule check)
• Permission to create a custom object and a workflow in the CRM
• Access to the notification delivery channel (email, SMS, or push) that the digest will use
• An existing notification trigger that fires when the source event occurs

If the notification source cannot attach a timestamp, the workflow must capture the arrival time at the moment the record is created.

The queue exists to separate notification receipt from notification delivery. Receipt happens in real time; delivery happens on a schedule.

Digest send window

The send window must be defined in the business's local time zone, because the definition of "morning" is specific to the team that receives the digest.

Sent stamp

Without the stamp, a record can be delivered twice if the workflow is re-run, retried, or triggered by an upstream event that fires more than once.

The pattern has three stages:

1. Capture — A notification arrives after hours and creates a queue record in the CRM custom object.
2. Hold — The record sits in the queue, unsent, until the digest send window.
3. Deliver — At the configured morning time, the workflow selects unsent records, bundles them into one message, sends the digest, and stamps each record as sent.

This design ensures the operator receives exactly one notification per after-hours period, regardless of how many individual alerts were generated overnight.

Step 1 — Create the notification queue custom object

Create a custom object in the CRM to hold queued notifications. At minimum, the object requires these fields:

The sent_at field is the sent stamp. An empty sent_at means the record has not been delivered.

Step 2 — Configure the capture workflow

Create a workflow that runs when the notification source fires. The workflow must:

1. Check whether the current time falls inside or outside business hours.
2. If inside business hours, deliver the notification immediately through the normal channel.
3. If outside business hours, create a record in the queue object with the notification details and the current time in received_at.

The business hours check is the branch that determines the delivery path. If the notification source cannot evaluate a schedule directly, the workflow can compare the current time against configured start and end times.

Step 3 — Configure the digest workflow

Create a second workflow that runs at the configured morning time. The workflow must:

1. Query the queue object for records where sent_at is empty.
2. If no records are found, end without sending.
3. If records are found, build a single message that combines every unsent record into one digest.
4. Send the digest through the configured delivery channel.
5. After a successful send, set sent_at on every included record to the current time and set digest_id to the identifier for this run.

The order matters. Set the sent stamp only after the send succeeds. If the send fails, the records remain unsent and will be included in the next digest run.

Step 4 — Test with a single notification

Send a single test notification during after-hours and confirm:

• A queue record is created with the expected details.
• No individual alert reaches the operator.
• At the digest time, the digest is sent with exactly one item.
• The sent_at field is populated on the queue record after delivery.

Step 5 — Test with multiple notifications

Send several test notifications during after-hours and confirm:

• Each notification creates its own queue record.
• The morning digest contains all of them in a single message.
• After the digest, every included record has a sent_at value.
• Re-running the digest workflow sends nothing, because no unsent records remain.

After implementation, the observable behavior should be:

• An after-hours notification creates a queue record but does not alert the operator immediately.
• Exactly one digest is sent at the configured morning time.
• The digest contains every notification that arrived since the last digest run.
• No notification is delivered twice, because the sent stamp prevents re-selection.
• If no notifications arrive overnight, no digest is sent at all.

An illustrative digest message might look like:

3 notifications received overnight:

1. Order #4821 — Payment failed (01:12)
2. Order #4821 — Payment retry succeeded (02:03)
3. Warehouse #7 — Stock level below threshold (04:47)

Each item includes the reference and the time the original notification arrived.

The digest contains duplicate notifications

Check: Inspect the queue records for the affected period and confirm whether sent_at is populated.

Resolution: Ensure the sent stamp is written in the same workflow run that sends the digest, and that selection for the digest queries only records where sent_at is empty. If duplicates exist from a previous run, stamp the affected records manually or delete them.

No digest is sent even though notifications arrived

Check: Verify the workflow schedule, the time zone of the configured digest time, and the query condition on sent_at.

Resolution: Confirm the workflow runs at the intended time in the intended time zone. Check the query filter and confirm the records are visible to the workflow's query scope.

Notifications still alert the operator individually after hours

Check: Review the branch logic in the capture workflow and confirm the schedule values used by the check.

Resolution: Correct the business hours configuration and verify that the workflow routes after-hours notifications to queue creation rather than immediate delivery.

The sent stamp is not applied after a successful send

Check: Review the workflow run history for the digest run and inspect the records that were sent but remain unstamped.

Resolution: Change the workflow so the stamp update is unconditional after a successful send. If a failure interrupted the run, apply the stamp manually to the affected records or allow the next digest run to include them.

• Store queue records with the same access controls as the source data they represent.
• Restrict the digest workflow to run under a service account with least-privilege access to the queue object.
• Do not include full credentials, tokens, or secrets in notification details; reference the record instead.
• Retain the digest_id and sent_at fields for audit so you can trace which records were delivered in which digest.

• Immediately-delivered vs queued notification routing
• Scheduling workflow triggers with business-hour calendars
• Deduplicating workflow runs with state stamps
• Audit trails for automated notification delivery