Reminder Operations: Audit Trail, Identity, and Retry

Overview

Reminder operations are reviewed from Reminder History at Admin/Reminders/History. The screen is titled Reminder Run History + Delivery Log and shows sent time, rule, recipient, channel, delivery status, provider id, actor, error, variables, and a Retry action for failed dispatch rows.

Prerequisites

• The user must be a district admin with access to district email settings.
• Viewing the history screen requires notifications.reminders.logs.read.
• Retrying a failed dispatch requires notifications.reminders.manage.
• API audit export requires the audit-export policy for reminder notifications.

Step-by-step procedure

1. Open Admin and select Reminder History.
2. Use Rule to filter delivery logs to one rule or keep All rules.
3. Use Channel to filter by one delivery channel or keep All channels.
4. Enter From UTC and To UTC when a specific delivery window is needed.
5. Select Go to refresh the delivery log.
6. Review each dispatch row:
   • Sent (UTC) shows when the dispatch was recorded.
   • Rule shows the reminder rule name when available.
   • Recipient shows the attempted destination.
   • Channel is currently email.
   • Status is Queued, Sent, Failed, or Skipped.
   • Provider Id shows the provider message id when one exists.
   • Actor shows the actor identity, or System when no actor identity was recorded.
   • Error shows the recorded failure text when one exists.
   • Variables opens the VariablesUsedJson payload.
7. Open Variables to review the Variable snapshot used to render the message for that recipient.
8. For a failed dispatch row, select Retry. The retry posts the dispatch log id and correlation id, then returns to Reminder History.

Actor identity and system identity

The delivery log preserves both the numeric actor user id and the text actor identity when available.

• Actor identity: manual actions such as retry use the signed-in user identity when available. If the API identity name is blank during retry, it records User:ReminderManualRetry.
• System identity: automated dispatch uses the reminder job identity. In the UI, a blank actor identity is displayed as System.
• The dispatch service uses System:ReminderDispatchJob for automated reminder-job work.

Variations / branching flows

• Retry by dispatch log: pass DispatchLogId when retrying one failed dispatch row.
• Retry by correlation id: pass CorrelationId when retrying the latest failed dispatch for a correlation.

Expected outcomes

• A successful Retry creates a new retry dispatch log with a new retry correlation id.
• Retry attempts only recipients that failed in the source dispatch.
• Recipients already sent in an equivalent dispatch window are skipped with IDEMPOTENCY_SKIP.
• The retry response includes source dispatch/correlation ids, retry dispatch/correlation ids, attempted count, sent count, failed count, and skipped count.
• The UI success toast reports sent, failed, and skipped counts when the retry response is available.

Troubleshooting / edge cases

• DispatchLogId or CorrelationId is required: retry requests must identify the failed dispatch.
• Failed dispatch not found for retry: the selected dispatch must still have failed status.
• No failed recipients were found: retry only works when the selected dispatch has failed recipient rows.
• Retry shows skipped recipients: the service skips recipients that already have a successful send in the same equivalent dispatch window.
• No delivery logs found: widen the UTC window, clear the rule/channel filter, or confirm that the reminder job has run.
• Variables are blank: not every row has VariablesUsedJson; blank variables display as a dash in the UI.
• Provider id is blank: queued, skipped, or provider-failed attempts might not have a provider message id.

Related processes

• Manage Automated Reminder Rules
• Reminder Templates: Placeholders and Version History
• Configure Tenant Settings and Options

Assumptions and gaps

• The current Razor view exposes delivery logs and manual retry. The audit export exists in the API but is not shown as a dedicated export button on the admin Reminder History screen.
• Retry creates queued recipient rows for eligible failed recipients; final provider delivery is completed by the reminder dispatch flow rather than by the history table itself.