Recalculation Run
What It Is
A recalculation run records an administrator’s request to bring existing CRM placements into line with regional policy. It represents a piece of processing with its own identity, progress and outcome. Saving settings or rules does not start this work automatically. The administrator chooses when the new coverage should be applied to the workspace’s contacts and organizations.
The run traverses contacts before organizations. Small amounts of work can finish during the request that starts it, while remaining batches continue in the background. Progress remains stored between batches, so processing resumes beyond committed work after an interruption. A completed run provides evidence that traversal finished, while its generation identifies the policy state under which the run began.
What It Is Not
Recalculation is separate from assignment following one record’s address change. Both share the same decision process, but a run revisits existing records even when their remembered deciding inputs have not changed. It is also separate from a regional file-import job and does not offer the import engine’s cancellation or control actions.
A completed run does not guarantee that every record changed or that every record is eligible for assignment. Overrides, update locks and the absence of a past or present deciding address can preserve existing values. Rules changed during processing can also leave another recalculation needed after this run completes.
How It Is Used
Administrators see a need banner when the current policy generation lacks a successful run. They start processing from the available recalculation action and inspect its progress. Readers can inspect run records without starting work. The console refreshes active processing and can find a run already underway when the page opens.
Only one run remains running in a workspace. Another start request returns that run and may process additional batches during its own budget. Workers coordinate committed progress rather than repeating the traversal. The run uses the policy read by each batch, so it does not freeze coverage at the moment it starts. Staff should consider the outstanding-policy signal alongside completion when deciding whether more processing is necessary.
Its Facets
Processing status. Running identifies unfinished work, completed identifies a finished traversal and failed identifies a final unsuccessful delivery.
Traversal position. The current phase and saved position allow a worker to resume contact or organization processing without replaying committed batches.
Work counts. Examined counts every traversed record, including records assignment skips. Changed counts actual regional values set or cleared.
Redacted failure. A failed database batch records the error kind and database code rather than bound values or the statement. Successful progress clears the earlier reason.
Workspace exclusivity. A second running run cannot be created for the same workspace. Completed or failed history does not prevent a new request.
Outstanding policy changes. The settings compare their generation with successful runs. This detects policy changes even when their timestamps coincide with a run’s start.
How It Relates
The policy supplies current coverage and regional placement supplies the values being reevaluated. Contact and organization persistence retains ownership of record updates. Shared change-event delivery provides continuation and retry rather than a regional queue or schedule of its own.
What It Could Become
The product should decide whether cancellation or explicit recovery controls are needed beyond starting another run after final failure. It should also consider whether examined is clear enough when it includes skipped records. Policy snapshotting would change the present per-batch behavior and needs an explicit design decision.