Delivery operations

Weekly proof needs recipient control, delivery history, and schedule guardrails.

See how SIRJ handles weekly recipients, email delivery, due-send timezone windows, sent and failed notification records, active alerts, rate limits, and tenant-scoped notification history.

Review weekly insights Open client workspaces Roles and permissions Schedule guardrails Usage controls Reports workflow

Buyer answers

Show who receives weekly proof and what happened after send.

Weekly reporting automation needs more than a send button. Teams need recipient scope, delivery state, schedule reason, alert state, and notification history close to the client workspace.

Delivery answer

What does SIRJ track for weekly delivery?

SIRJ tracks configured weekly recipients, the generated weekly insight, recipient email delivery attempts, sent or failed status, provider message id when available, error text when delivery fails, week label metadata, dashboard URL metadata, active anomaly alerts, and occurred-at timestamps.

A team can distinguish a delivered weekly proof email from a failed send or active alert before a client asks whether the report was actually sent.

Review the supporting path

Delivery answer

Where are weekly recipients configured?

Weekly recipients belong to the client workspace. The runtime accepts recipient input for a specific client, normalizes email addresses, stores the list on that workspace, and uses that list for scheduled delivery when the workspace and plan allow weekly emails.

Recipient lists stay client-specific, so an agency can send weekly proof to the right client contacts without turning one account-wide list into every client's delivery path.

Review the supporting path

Delivery answer

How does SIRJ avoid duplicate scheduled emails?

The due-send workflow checks the configured weekly schedule, client timezone, current time, and latest sent weekly notification before doing dashboard or email work. It returns due, already sent, or not due instead of sending blindly.

Automated reporting stays predictable: the product can explain why it sent, why it skipped, or why a previous sent record blocked a duplicate delivery.

Review the supporting path

Delivery answer

How does notification history stay tenant-scoped?

Notification center construction creates the active account and client scope, asserts each notification record belongs to that same scope, sorts rows newest first, and returns sent, failed, and active counts for the selected workspace only.

Delivery history is useful because it is scoped to the same client workspace as the dashboard, report, recipient list, and weekly insight.

Review the supporting path

Delivery workflow

Recipients, schedule checks, and notification history stay in one proof path.

The public page shows how recipient configuration, plan and role checks, due-send guardrails, email delivery, and notification history work together before weekly proof becomes client-facing.

Store client-specific recipients Check permission and feature access Apply schedule guardrails Send and record each recipient Show scoped notification history

Recipient controls

Recipient lists belong to the client workspace.

A delivery system only earns trust when contacts are scoped, normalized, permissioned, and connected to the plan feature that sends weekly emails.

Control	User sees	System path
Client workspace list	A workspace-level recipient list that can include the owner, client sponsor, operator, or analyst who should receive weekly proof.	Client workspace records store weeklyRecipients after the runtime updates the selected client's recipient list.
Email normalization	Recipient addresses are trimmed and normalized to lowercase instead of preserving inconsistent casing or blank entries.	createClientWorkspace normalizes weeklyRecipients and rejects entries that are not valid email addresses.
Client-specific update route	Updating weekly recipients targets one client workspace, not every client attached to the agency account.	The API parses /clients/[clientId]/weekly-recipients, switches active client context, enforces client administration permission, and saves the workspace-specific list.
Plan and feature gate	Weekly delivery only runs when the workspace, subscription feature, email client, recipients, and notification history store are ready.	API runtime enforces the weekly email tier feature before manual or due delivery, and heartbeat checks workspace recipients before due sends run.

Delivery records

Each send path should leave a reviewable record.

Manual sends, scheduled due sends, provider successes, provider failures, and active anomaly alerts each answer a different operations question.

Stage	Reviewer sees	Protected behavior
Manual weekly send	A requested weekly email send returns generated insights, per-recipient sent or failed delivery records, and active anomaly alert records.	The request requires report-export permission, applies the weekly delivery rate limit, and records delivery state instead of treating the email as fire-and-forget.
Due scheduled send	The due-send response says whether it sent, why it sent or skipped, the schedule, last sent timestamp, notifications, and anomaly alerts.	The workflow checks timezone schedule and latest sent notification before building dashboard data or sending email.
Email provider success	Sent records include recipient, subject, provider message id when returned, dashboard URL metadata, week label metadata, and occurred-at timestamp.	Successful sends create notification records with weekly_insights_email type and sent status for the active account and client.
Email provider failure	Failed records include recipient, subject, error, dashboard URL metadata, week label metadata, and occurred-at timestamp.	A failed recipient does not erase successful sends to other recipients, and the error becomes reviewable in notification history.
Active anomaly alert	Active alert records are assigned to the dashboard recipient and include week label, dashboard URL, severity, and anomaly metadata.	Alert records remain tied to generated dashboard insight data instead of becoming a separate notification stream without evidence.

Schedule states

Due-send automation needs a visible reason for every outcome.

The system should be able to explain whether it sent, skipped because the email already sent, or skipped because the configured timezone window is not open yet.

State	Condition	Result
Due	The schedule window is open for the configured client timezone and no recent sent weekly email blocks the current send.	SIRJ builds the dashboard, generates weekly insights, sends configured recipients, saves sent or failed notifications, and records active anomaly alerts.
Already sent	The schedule window is open, but recent notification history shows a sent weekly email already happened inside the guarded window.	SIRJ skips dashboard and email work, returns already_sent, exposes lastSentAt, and leaves notifications empty for the duplicate attempt.
Not due	The current time is outside the Monday 7:00 schedule window for the configured timezone, so the system should not build dashboard data or contact recipients yet.	SIRJ skips dashboard and email work, returns not_due, and does not create notification records for the skipped pass.

Workflow

Delivery proof moves from recipient setup to scoped history.

Workflow

Store client-specific recipients

Weekly delivery starts with a recipient list attached to the selected client workspace and normalized before delivery uses it.

Client workspace and team views can show who receives weekly reporting without mixing client contacts across the account.

Inspect this path

Workflow

Check permission and feature access

Manual and due-send weekly delivery require report-export permission and the weekly email feature before delivery can run.

Pricing, roles, and billing pages explain which plan and role can operate weekly delivery instead of hiding it behind a silent failure.

Inspect this path

Workflow

Apply schedule guardrails

Due-send delivery reads notification history, schedule, timezone, and current time before deciding whether to send, skip as already sent, or skip as not due.

The response can explain sent, already-sent, and not-due outcomes with schedule and last-sent context.

Inspect this path

Workflow

Send and record each recipient

Weekly delivery loops through each recipient, renders the weekly email, calls the email client, and writes one sent or failed notification record per recipient.

Delivery history can show a successful recipient beside a failed recipient without collapsing both outcomes into one vague status.

Inspect this path

Workflow

Show scoped notification history

Notification center rows are sorted newest first and counted by sent, failed, and active status after tenant-scope checks pass.

The selected client workspace shows notification history that belongs to that same account and client only.

Inspect this path

Standards

Keep weekly delivery scoped, explainable, and recoverable.

Standard

Do not use one recipient list for every client

A shared recipient list can send private client reporting to the wrong stakeholder or make agencies afraid to turn weekly delivery on.

Weekly recipients live on the client workspace, and the runtime updates the selected client context before saving the recipient list.

Standard

Do not hide failed sends

If a failed email disappears, the team may believe client proof was delivered when the client never received it.

Delivery creates failed notification records with recipient, subject, error, metadata, and timestamp while preserving successful records for other recipients.

Standard

Do not send twice inside the schedule window

Duplicate weekly emails make automation look sloppy and force the agency to explain which version the client should trust.

Due-send checks recent sent notification history before building dashboard data or sending email again, then returns an already-sent state with lastSentAt for review.

Standard

Do not show cross-client notification history

Notification rows include recipients, subjects, errors, and dashboard links that should never appear in the wrong workspace.

Notification center construction asserts account and client scope for every record before returning counts or rows.

FAQ

Notification delivery and recipient questions.

Can SIRJ send weekly insights to multiple recipients?

Yes. Weekly delivery accepts multiple configured recipients for a client workspace and creates a sent or failed notification record for each recipient.

Can SIRJ show whether a weekly email failed?

Yes. Failed sends become notification records with recipient, subject, error, dashboard URL metadata, week label metadata, and timestamp.

How does SIRJ avoid duplicate scheduled weekly sends?

The due-send workflow checks the weekly schedule, configured timezone, current time, and latest sent notification before sending. It can return due, already_sent, or not_due.

Are notification records scoped to one client workspace?

Yes. Notification center construction asserts account and client scope for every notification record before showing sent, failed, active counts, or rows.

Delivery review

Before weekly proof becomes client communication, verify who gets it and what happened.

Review weekly insight generation, recipient controls, delivery status, schedule guardrails, and notification history from the same source-backed reporting path.

Review weekly insights Open client workspaces

Delivery operations

Weekly proof needs recipient control, delivery history, and schedule guardrails.

See how SIRJ handles weekly recipients, email delivery, due-send timezone windows, sent and failed notification records, active alerts, rate limits, and tenant-scoped notification history.

Review weekly insights Open client workspaces Roles and permissions Schedule guardrails Usage controls Reports workflow

Buyer answers

Show who receives weekly proof and what happened after send.

Weekly reporting automation needs more than a send button. Teams need recipient scope, delivery state, schedule reason, alert state, and notification history close to the client workspace.

Delivery answer

What does SIRJ track for weekly delivery?

A team can distinguish a delivered weekly proof email from a failed send or active alert before a client asks whether the report was actually sent.

Review the supporting path

Delivery answer

Where are weekly recipients configured?

Recipient lists stay client-specific, so an agency can send weekly proof to the right client contacts without turning one account-wide list into every client's delivery path.

Review the supporting path

Delivery answer

How does SIRJ avoid duplicate scheduled emails?

Automated reporting stays predictable: the product can explain why it sent, why it skipped, or why a previous sent record blocked a duplicate delivery.

Review the supporting path

Delivery answer

How does notification history stay tenant-scoped?

Delivery history is useful because it is scoped to the same client workspace as the dashboard, report, recipient list, and weekly insight.

Review the supporting path

Delivery workflow

Recipients, schedule checks, and notification history stay in one proof path.

The public page shows how recipient configuration, plan and role checks, due-send guardrails, email delivery, and notification history work together before weekly proof becomes client-facing.

Store client-specific recipients Check permission and feature access Apply schedule guardrails Send and record each recipient Show scoped notification history

Recipient controls

Recipient lists belong to the client workspace.

A delivery system only earns trust when contacts are scoped, normalized, permissioned, and connected to the plan feature that sends weekly emails.

Control	User sees	System path
Client workspace list	A workspace-level recipient list that can include the owner, client sponsor, operator, or analyst who should receive weekly proof.	Client workspace records store weeklyRecipients after the runtime updates the selected client's recipient list.
Email normalization	Recipient addresses are trimmed and normalized to lowercase instead of preserving inconsistent casing or blank entries.	createClientWorkspace normalizes weeklyRecipients and rejects entries that are not valid email addresses.
Client-specific update route	Updating weekly recipients targets one client workspace, not every client attached to the agency account.	The API parses /clients/[clientId]/weekly-recipients, switches active client context, enforces client administration permission, and saves the workspace-specific list.
Plan and feature gate	Weekly delivery only runs when the workspace, subscription feature, email client, recipients, and notification history store are ready.	API runtime enforces the weekly email tier feature before manual or due delivery, and heartbeat checks workspace recipients before due sends run.

Delivery records

Each send path should leave a reviewable record.

Manual sends, scheduled due sends, provider successes, provider failures, and active anomaly alerts each answer a different operations question.

Stage	Reviewer sees	Protected behavior
Manual weekly send	A requested weekly email send returns generated insights, per-recipient sent or failed delivery records, and active anomaly alert records.	The request requires report-export permission, applies the weekly delivery rate limit, and records delivery state instead of treating the email as fire-and-forget.
Due scheduled send	The due-send response says whether it sent, why it sent or skipped, the schedule, last sent timestamp, notifications, and anomaly alerts.	The workflow checks timezone schedule and latest sent notification before building dashboard data or sending email.
Email provider success	Sent records include recipient, subject, provider message id when returned, dashboard URL metadata, week label metadata, and occurred-at timestamp.	Successful sends create notification records with weekly_insights_email type and sent status for the active account and client.
Email provider failure	Failed records include recipient, subject, error, dashboard URL metadata, week label metadata, and occurred-at timestamp.	A failed recipient does not erase successful sends to other recipients, and the error becomes reviewable in notification history.
Active anomaly alert	Active alert records are assigned to the dashboard recipient and include week label, dashboard URL, severity, and anomaly metadata.	Alert records remain tied to generated dashboard insight data instead of becoming a separate notification stream without evidence.

Schedule states

Due-send automation needs a visible reason for every outcome.

The system should be able to explain whether it sent, skipped because the email already sent, or skipped because the configured timezone window is not open yet.

State	Condition	Result
Due	The schedule window is open for the configured client timezone and no recent sent weekly email blocks the current send.	SIRJ builds the dashboard, generates weekly insights, sends configured recipients, saves sent or failed notifications, and records active anomaly alerts.
Already sent	The schedule window is open, but recent notification history shows a sent weekly email already happened inside the guarded window.	SIRJ skips dashboard and email work, returns already_sent, exposes lastSentAt, and leaves notifications empty for the duplicate attempt.
Not due	The current time is outside the Monday 7:00 schedule window for the configured timezone, so the system should not build dashboard data or contact recipients yet.	SIRJ skips dashboard and email work, returns not_due, and does not create notification records for the skipped pass.

Workflow

Delivery proof moves from recipient setup to scoped history.

Workflow

Store client-specific recipients

Weekly delivery starts with a recipient list attached to the selected client workspace and normalized before delivery uses it.

Client workspace and team views can show who receives weekly reporting without mixing client contacts across the account.

Inspect this path

Workflow

Check permission and feature access

Manual and due-send weekly delivery require report-export permission and the weekly email feature before delivery can run.

Pricing, roles, and billing pages explain which plan and role can operate weekly delivery instead of hiding it behind a silent failure.

Inspect this path

Workflow

Apply schedule guardrails

Due-send delivery reads notification history, schedule, timezone, and current time before deciding whether to send, skip as already sent, or skip as not due.

The response can explain sent, already-sent, and not-due outcomes with schedule and last-sent context.

Inspect this path

Workflow

Send and record each recipient

Weekly delivery loops through each recipient, renders the weekly email, calls the email client, and writes one sent or failed notification record per recipient.

Delivery history can show a successful recipient beside a failed recipient without collapsing both outcomes into one vague status.

Inspect this path

Workflow

Show scoped notification history

Notification center rows are sorted newest first and counted by sent, failed, and active status after tenant-scope checks pass.

The selected client workspace shows notification history that belongs to that same account and client only.

Inspect this path

Standards

Keep weekly delivery scoped, explainable, and recoverable.

Standard

Do not use one recipient list for every client

A shared recipient list can send private client reporting to the wrong stakeholder or make agencies afraid to turn weekly delivery on.

Weekly recipients live on the client workspace, and the runtime updates the selected client context before saving the recipient list.

Standard

Do not hide failed sends

If a failed email disappears, the team may believe client proof was delivered when the client never received it.

Delivery creates failed notification records with recipient, subject, error, metadata, and timestamp while preserving successful records for other recipients.

Standard

Do not send twice inside the schedule window

Duplicate weekly emails make automation look sloppy and force the agency to explain which version the client should trust.

Due-send checks recent sent notification history before building dashboard data or sending email again, then returns an already-sent state with lastSentAt for review.

Standard

Do not show cross-client notification history

Notification rows include recipients, subjects, errors, and dashboard links that should never appear in the wrong workspace.

Notification center construction asserts account and client scope for every record before returning counts or rows.

FAQ

Notification delivery and recipient questions.

Can SIRJ send weekly insights to multiple recipients?

Yes. Weekly delivery accepts multiple configured recipients for a client workspace and creates a sent or failed notification record for each recipient.

Can SIRJ show whether a weekly email failed?

Yes. Failed sends become notification records with recipient, subject, error, dashboard URL metadata, week label metadata, and timestamp.

How does SIRJ avoid duplicate scheduled weekly sends?

The due-send workflow checks the weekly schedule, configured timezone, current time, and latest sent notification before sending. It can return due, already_sent, or not_due.

Are notification records scoped to one client workspace?

Yes. Notification center construction asserts account and client scope for every notification record before showing sent, failed, active counts, or rows.

Delivery review

Before weekly proof becomes client communication, verify who gets it and what happened.

Review weekly insight generation, recipient controls, delivery status, schedule guardrails, and notification history from the same source-backed reporting path.

Review weekly insights Open client workspaces

Weekly proof needs recipient control, delivery history, and schedule guardrails.

Show who receives weekly proof and what happened after send.

What does SIRJ track for weekly delivery?

Where are weekly recipients configured?

How does SIRJ avoid duplicate scheduled emails?

How does notification history stay tenant-scoped?

Recipients, schedule checks, and notification history stay in one proof path.

Recipient lists belong to the client workspace.

Each send path should leave a reviewable record.

Due-send automation needs a visible reason for every outcome.

Delivery proof moves from recipient setup to scoped history.

Store client-specific recipients

Check permission and feature access

Apply schedule guardrails

Send and record each recipient

Show scoped notification history

Keep weekly delivery scoped, explainable, and recoverable.

Do not use one recipient list for every client

Do not hide failed sends

Do not send twice inside the schedule window

Do not show cross-client notification history

Notification delivery and recipient questions.

Can SIRJ send weekly insights to multiple recipients?

Can SIRJ show whether a weekly email failed?

How does SIRJ avoid duplicate scheduled weekly sends?

Are notification records scoped to one client workspace?

Before weekly proof becomes client communication, verify who gets it and what happened.

Preparing the source route.

Weekly proof needs recipient control, delivery history, and schedule guardrails.

Show who receives weekly proof and what happened after send.

What does SIRJ track for weekly delivery?

Where are weekly recipients configured?

How does SIRJ avoid duplicate scheduled emails?

How does notification history stay tenant-scoped?

Recipients, schedule checks, and notification history stay in one proof path.

Recipient lists belong to the client workspace.

Each send path should leave a reviewable record.

Due-send automation needs a visible reason for every outcome.

Delivery proof moves from recipient setup to scoped history.

Store client-specific recipients

Check permission and feature access

Apply schedule guardrails

Send and record each recipient

Show scoped notification history

Keep weekly delivery scoped, explainable, and recoverable.

Do not use one recipient list for every client

Do not hide failed sends

Do not send twice inside the schedule window

Do not show cross-client notification history

Notification delivery and recipient questions.

Can SIRJ send weekly insights to multiple recipients?

Can SIRJ show whether a weekly email failed?

How does SIRJ avoid duplicate scheduled weekly sends?

Are notification records scoped to one client workspace?

Before weekly proof becomes client communication, verify who gets it and what happened.