Represent deleted CRM records with tombstone semantics
A deleted record reappears when an old update is replayed.
- Focused work estimate
- 3h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Data lifecycle · Idempotency
Estimated field mix
- Data engineering40%
- Integrations30%
- Privacy engineering30%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional account team sees overwritten edits, duplicate contacts, and stale opt-out preferences after synchronization retries.
Setup prerequisites
- Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- BCRM-101 · Define contact field ownership between the app and CRM
- BCRM-102 · Separate external contact identity from email addresses
- BCRM-103 · Checkpoint CRM pagination only after local batch commit
- BCRM-104 · Apply contact updates with explicit conflict detection
- BCRM-105 · Propagate communication opt-outs ahead of ordinary profile updates
Acceptance criteria
- Retain deletion identity and source revision.
- Prevent older updates from resurrecting the record.
- Apply the documented retention rule to local fields.
Implementation constraints
- Deletion policy must distinguish identity metadata from contact contents.
Verification to include
- Apply a deletion then replay an older update.
- Verify an authorized new identity follows an explicit recreation path.
Deliverables
- Deletion and replay rules.
Rollout and recovery
Introduce tombstones before importing deletion events.
Value of the work
For the engineer: Practice sync cursors, conflict policies, privacy boundaries, and replay.
For the team: Provide predictable customer-data synchronization with inspectable conflicts.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.