Recalculate role compliance and submit the notice
What It Does
Recalculation compares effective role holders with an organization type’s expectations and persists the explanation of any failure. A chapter that loses its billing representative can move out of compliance after relationship work or a date boundary. If its type permits transition notices, CRM prepares submissions describing that same assessment.
Our reading is that the commit boundary matters because staff must not see a new assessment whose notice request describes an unrelated state. The local assessment and submission pointers commit together, but request-object storage and Platform delivery remain separate. A noncompliant badge is therefore not proof that anybody received mail.
What Starts It
A committed person or organization change reaches the compliance reaction, or authorized reprocessing reaches the organization. Date-sensitive work can also request evaluation when relevant boundaries pass. The evaluator reads current policy and eligible people under its organization boundary. Opening the organization screen merely reads the stored assessment and does not initiate a fresh calculation.
The Flow
The diagram shows the sequence and service seams. Each synchronous stage waits for its result, while captured-event, queue and scheduled stages can run after the originating request has returned. The hop descriptions below identify the write and failure boundary, so the last arrow must not be mistaken for one atomic transaction across every participant.
Hop by Hop
1. CRM change-events dispatcher
Event dispatch claims committed contact changes and sends one message per applicable handler. It removes captured events only after the required queue accepts all messages. This stage transports the trigger; it does not calculate coverage while the original contact save is still open.
2. Compliance recalculation handler
The compliance handler compares before-and-after relationship and role context to identify organizations needing evaluation. It also includes those whose old assessment needs clearing. The legacy save escape and import suppression affect this selection, while contact deletion still requests its own recalculation.
3. Entities compliance workflow (one transaction per organization)
For each organization, the evaluator locks the subject and counts distinct eligible holders on effective affiliations. It compares the type’s bounds and writes changed violations, status and enabled attention in one transaction. A result equal to storage avoids a redundant assessment write.
4. Entities compliance e-mail
An eligible transition notice is composed from the transaction’s organization and recipients. Sorted recipients are split into batches of at most five hundred. Request objects go to Platform storage, while deduplicated submission pointers are inserted locally; a failure in this stage aborts the assessment transaction.
5. Entities compliance workflow
Owned evaluation transactions ask for early communications dispatch after committing. Evaluation nested within batch work relies on the schedule instead. This nudge changes when publication may begin, not whether the already committed status exists or whether Platform will deliver a message.
6. Platform communications
Platform accepts the submissions and attempts communication using the current published owned template. It records delivery outcomes under its separate contract. Missing configuration or send failure can leave CRM’s valid noncompliant assessment without a delivered notice, and CRM does not close that gap by fabricating delivery feedback.
When Something Fails
Hop 1 — CRM change-events dispatcher
The failure boundary is: Retain or reclaim events that were not fully accepted. The remaining work or data is: Compliance can remain behind the committed contact. Dispatcher logs report publication attempts. A later attempt can be required; the scheduling or publication boundary does not establish an immediate user-visible completion.
Hop 2 — Compliance recalculation handler
The failure boundary is: Throw on failure so SQS retries and eventually dead-letters the handler message. The remaining work or data is: Affected organizations retain previous compliance until another successful trigger. Consumer logs and handler dead-letter messages expose the failure. This failure is downstream of committed input; operators investigate its own delivery rather than treating the caller’s original save as failed.
Hop 3 — Entities compliance workflow (one transaction per organization)
The failure boundary is: Roll back the evaluation transaction and fail its handler delivery. The remaining work or data is: No partial business write remains. Organization revisions show committed recalculation.
Hop 4 — Entities compliance e-mail
The failure boundary is: Fail and roll back recalculation if composition, storage or submission insertion fails. The remaining work or data is: A stored request object can survive rollback until the bucket’s 30-day expiry. Platform submission and communication records show accepted batches.
Hop 5 — Entities compliance workflow
The failure boundary is: Ignore a failed nudge and allow the schedule to attempt publication later. The remaining work or data is: Submissions can wait beyond one dispatch interval. Communication dispatcher logs show publication attempts. A later attempt can be required; the scheduling or publication boundary does not establish an immediate user-visible completion.
Hop 6 — Platform communications
The failure boundary is: Missing template configuration blocks delivery; other failures use Platform retry policy. The remaining work or data is: The organization may remain noncompliant without any delivered notice, and CRM has no delivery feedback loop. Platform communication outcomes identify blocked or failed sends. This failure is downstream of committed input; operators investigate its own delivery rather than treating the caller’s original save as failed.
Repeats and Races
Evaluation reads committed state again on a repeated trigger and avoids writing unchanged compared violations. Notice batch keys include the organization, resulting version and batch index, so repeated accepted submissions deduplicate at that boundary. Multiple batches can still exist for one transition, and no key establishes guaranteed delivery.
The organization advisory lock and row lock serialize competing recalculations. They do not pin all people and policy for a workspace-wide instant. A contact committed later produces another reaction. Continuing noncompliance and a new transition have different notice behavior, and recipient selection distinguishes absence from an explicit empty list.
What Is Observable
Dispatcher logs report publication attempts. Consumer logs and handler dead-letter messages expose the failure. Organization revisions show committed recalculation. Platform submission and communication records show accepted batches. Communication dispatcher logs show publication attempts. Platform communication outcomes identify blocked or failed sends.
The person or initiating caller sees the synchronous result at its own boundary. Captured history establishes committed local changes; logs, durable job state and queue outcomes explain remaining work. A successful database change, accepted downstream request and completed delivery are different observations and must be investigated through the component that owns each one.
Open Design Questions
The existing findings retain missing delivery feedback, policy-change timing and recipient or replay proof limits. Object storage can retain an orphaned request after database rollback until storage expiry. Operators must use communication outcomes to investigate actual delivery rather than treating the organization revision as a mail receipt.