Disconnect and resolve shared contact details
What It Does
This flow preserves a person’s last known detail when its organization source disappears, then lets staff make an explicit recovery choice. If Harbor Engineering removes its main address, Ruth’s linked work address becomes disconnected information with an explanation, rather than a dangling reference or a silently confirmed independent value.
The recorded disconnection decision establishes that preservation behavior. Our reading is that showing source, cause and time helps staff distinguish this situation from a tie that simply ended. Recovery changes the contact under current-version checks; displaying the warning alone does not verify the address.
What Starts It
An organization save removes a shared address or telephone source, or an organization merge removes its source identity. That transaction starts preservation of dependent contact values. Later a contact editor opens the retained disconnected detail and chooses an allowed resolution. Source loss and staff recovery are separate transactions; seeing a warning alone changes neither the retained value nor its verification state.
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. Organization save
An organization save removes an address or phone source, or a merge absorbs its organization. This is the transaction initiating source loss. If the save fails, the source and existing live references remain; staff cannot observe a committed removal without the corresponding transactional effects.
2. Database trigger
The database trigger snapshots every dependent contact detail and records the organization, time and reason for disconnection. It advances affected owner versions and captures their changes. Trigger failure rolls back source removal and all snapshots together, preserving the link’s referential boundary.
3. CRM change-event consumers
Region and search handlers receive the relevant changes after commit. They can process the organization and affected contacts independently. The disconnected contact value already exists while these projections refresh, so a delayed region update is not evidence that preservation failed.
4. Contact 360
Contact 360 presents the disconnection explanation to readers and supported recovery controls to editors. Showing this state is not a mutation. The detail remains marked for verification until an authorized version-tested save or dedicated action actually settles it.
5. Console, or an integration calling the dedicated actions
The console rereads and patches the containing collection; integrations can call dedicated keep, relink or remove actions. Dedicated routes additionally require the row still be disconnected. Keeping establishes owned information, relinking selects a valid effective source, and removal deletes the detail after applicable guards.
When Something Fails
Hop 1 — Organization save
The failure boundary is: Rollback leaves the source and contact links unchanged. The remaining work or data is: No partial business write remains. The caller receives the result.
Hop 2 — Database trigger
The failure boundary is: Trigger failure aborts source removal and all disconnections. The remaining work or data is: No partial business write remains. Affected histories and contact reads show disconnection.
Hop 3 — CRM change-event consumers
The failure boundary is: Retry failed SQS handlers and dead-letter after five receives. The remaining work or data is: Regions and search can lag the committed disconnection. Consumer logs expose failed projections. This failure is downstream of committed input; operators investigate its own delivery rather than treating the caller’s original save as failed.
Hop 4 — Contact 360
The failure boundary is: Rendering alone does not mutate or repair the detail. The remaining work or data is: Disconnection remains until a user successfully resolves it. Contact readers see verification status.
Hop 5 — Console, or an integration calling the dedicated actions
The failure boundary is: Version conflicts require reload. Dedicated APIs additionally refuse a row already resolved. The remaining work or data is: A failed save leaves the disconnected value available for another attempt. The console presents a toast or field error.
Repeats and Races
The source-removal transaction and all disconnections have one commit boundary. After that commit, current contact versions order recovery against other edits. A dedicated action checks both version and still-disconnected state; a repeated resolution cannot quietly apply to a row already settled by somebody else.
The console’s collection patch uses general save validation instead of the dedicated action’s state predicate. An archived contact requires restoration before ordinary recovery. Calendar expiry alone creates unresolved read behavior, not disconnection provenance, and source removal is therefore not interchangeable with an employer departure.
What Is Observable
The caller receives the result. Affected histories and contact reads show disconnection. Consumer logs expose failed projections. Contact readers see verification status. The console presents a toast or field error.
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 dedicated API and built console recovery paths have different state checks, as retained in the existing findings. Projection lag and verification of the person’s chosen replacement remain separate concerns. No source evidence establishes that viewing a warning or pressing Keep independently validates a postal address with the person.