Audit Trail, Privacy & Compensating Strategies

The CRM domain maintains a comprehensive, immutable audit trail for every relationship, opportunity, and service interaction. Corrections are achieved through compensating documents and controlled merge procedures rather than record destruction.

---

1. CRM Audit Trail

Every mutation within the CRM context is recorded with immutable context. The audit trail supports sales management, service accountability, privacy compliance, and regulatory scrutiny.

Audit Attributes

Attribute	Purpose
Actor Identity	Identifies the sales rep, support agent, marketer, system job, or integration process that initiated the action.
Timestamp	Records the precise moment of the action in UTC and the user’s local time zone.
Origin Context	Identifies the source module, engagement tool, or API integration that triggered the action.
Before / After Snapshot	Captures the state of the lead, deal, contact, account, or ticket before and after the change.
Reason Code	Captures the business justification for the mutation, especially for stage regressions, disqualifications, and merges.
Linked Entities	Identifies related contacts, accounts, deals, tickets, or campaigns affected by the change.

Audit Invariants

• Audit log entries are append-only. They can never be edited or deleted.
• Closed-Won deals retain a complete lineage of stage changes, value revisions, and closure details.
• Lead disqualifications and requalifications are permanently linked to reason codes.
• Ticket SLA breaches, escalations, and reopen events are recorded with full time calculations.
• Contact merges and account merges retain both original and surviving record identifiers.

---

2. GDPR / Privacy Compliance

The CRM domain supports privacy regulations such as GDPR, CCPA, and equivalent frameworks by design. Personal data is managed with consent, minimization, retention, and erasure controls.

Privacy Principles

Principle	Implementation
Lawful Basis	Every contact record carries a lawful basis for processing (consent, contract, legitimate interest, legal obligation).
Consent Management	Consent is captured with purpose, timestamp, source, and withdrawal mechanism.
Data Minimization	Only data necessary for the stated commercial purpose is collected and retained.
Retention Limits	Data retention periods are defined per data category; expired records are flagged for review or pseudonymization.
Right of Access	Individuals can request a complete export of their personal data held in CRM.
Right to Rectification	Individuals can request correction of inaccurate personal data.
Right to Object	Individuals can object to marketing processing; opt-outs are applied immediately.

Right to be Forgotten

The CRM domain implements the right to erasure through pseudonymization rather than physical deletion wherever historical transactional integrity must be preserved.

Pseudonymization Strategy

Data Element	Erasure Action
Name	Replaced with non-identifiable token (e.g., DELETED_12345).
Email	Replaced with hashed or masked placeholder.
Phone	Replaced with masked placeholder.
Address	Removed or generalized.
Touchpoint Content	Content scrubbed of personal references; metadata retained.
Deal / Ticket History	Retained with pseudonymized requester/contact reference.
Audit Trail	Retained to document erasure action and preserve accountability.

When Full Deletion Is Permitted

Full deletion is permitted only when:

• There is no overriding legal or contractual obligation to retain the data.
• The data is not required for pending disputes, regulatory investigations, or financial audits.
• All downstream subscribers have been notified and have completed their own erasure obligations.

Consent Withdrawal Propagation

When consent is withdrawn:

1. The contact’s marketing consent status is updated immediately.
2. A ConsentUpdated event is emitted.
3. Marketing automation and engagement tools consume the event and suppress further communications.
4. Existing scheduled campaigns remove the contact from future sends.
5. Withdrawal is recorded in the audit trail with timestamp and source.

---

3. Deduplication & Merging Policies

Duplicate contacts and accounts are inevitable in a multi-channel CRM. The domain handles deduplication through detection, review, and explicit merge procedures.

Duplicate Detection Process

flowchart TD
    A[New Record Created] --> B[Canonical Key Check]
    B --> C{Duplicate Found?}
    C -->|No| D[Record Confirmed Unique]
    C -->|Yes| E[Confidence Scoring]
    E --> F{Auto-Merge Eligible?}
    F -->|Yes| G[Auto-Merge with Audit]
    F -->|No| H[Merge Review Queue]
    H --> I{User Decision}
    I -->|Merge| J[Manual Merge with Audit]
    I -->|Ignore| K[Duplicate Dismissed with Reason]
    I -->|Not Duplicate| D

Merge Rules

Rule	Invariant
Survivor Selection	One record is designated as the survivor; all others become merged ancestors.
History Transfer	All touchpoints, deals, tickets, activities, and campaign attributions transfer to the survivor.
Original IDs Preserved	Merged record IDs are retained in a merge history table for traceability.
No Data Loss	Conflicting field values are resolved through merge policy (e.g., most recent, most complete, manual selection).
Event Emission	A ContactMerged or AccountMerged event is emitted so downstream contexts can update aliases.
No Silent Merge	Automatic merging is restricted to exact-key matches; all other matches require review.

Field Conflict Resolution

Conflict Scenario	Resolution Policy
Different phone numbers	Both numbers retained; primary flagged per policy.
Different job titles	Most recent value wins unless manual override.
Different account associations	Both associations retained where the domain supports multiple account links; otherwise manual review.
Different consent statuses	Most restrictive consent status wins.
Different owner assignments	Surviving record owner retained; merged owners noted in history.

Downstream Alias Consolidation

When a merge occurs:

• Sales / OMS updates customer aliases on quotes and orders.
• FMS consolidates customer master references.
• Marketing automation merges audience segments and suppression lists.
• Support desk updates ticket requester references.

---

4. Compensating Strategies

The CRM domain does not allow retroactive editing of terminal states or deletion of historical records. Corrections follow formal compensating strategies.

Why Record Destruction Is Restricted

Deleting relationship records would break:

• The immutable audit trail required for sales and service accountability.
• The integrity of pipeline history and commission calculations.
• The ability to reproduce historical forecasts and reports.
• Regulatory compliance with data retention and privacy laws.

Correction Strategies

Correction Scenario	Compensating Document / Action	Description
Deal value error after closure	Deal Amendment Note + compensating action in Sales/FMS.	Original Closed-Won deal remains sealed; correction applied downstream.
Incorrect account on deal	Account Reassignment Record + alias update.	Deal reassigned to correct account with audit trail; downstream aliases updated.
Wrong contact marked as decision maker	Buying Center Update	Role corrected for current and future deals; history preserved.
Ticket incorrectly resolved	Ticket Reopen	Reopen event created; SLA recalculated; resolution history retained.
Lead incorrectly disqualified	Requalification Event	New qualification event recorded; original disqualification reason retained.
Duplicate records discovered	Merge Record	Explicit merge with history transfer and downstream alias consolidation.
Consent status error	Consent Correction Event	Updated consent with reason; withdrawal reprocessed if necessary.

---

5. Sales Commission & Forecast Protection

Because Closed-Won deals are sealed, corrections that affect commissions or forecasts must be handled carefully:

Scenario	Handling Rule
Deal canceled after Closed-Won	Cancellation processed in Sales / OMS and FMS; original deal remains Closed-Won; commission clawback handled by compensation system.
Deal value reduced after closure	Credit note or amendment processed downstream; CRM records amendment note only.
Deal wrongly attributed to owner	Owner reassignment for future reporting only; historical attribution preserved for commission payout.
Forecast category misclassified	Reclassification audited; prior period forecasts remain unchanged.

---

6. Support Desk Audit & Compliance

Support operations require additional audit controls for service level accountability:

Control	Implementation
SLA Calculation Audit	Every SLA breach stores the complete calculation: target, elapsed time, calendar used, pause intervals.
Escalation Audit	Escalations record trigger reason, previous assignee, new assignee, and timestamp.
Reopen Audit	Reopened tickets record customer reason, previous resolution, and new SLA calculation.
Agent Override Audit	Any manual priority or SLA change requires reason code and manager approval.
Customer Satisfaction Audit	CSAT responses are linked to ticket, agent, and resolution for quality reporting.

---

7. Summary

The CRM domain in Obelaw is a rigorous, event-driven bounded context that enforces relationship integrity through immutable records, explicit merge procedures, sealed deal states, strict SLA calculations, and privacy-aware data handling. It remains isolated from operational and financial contexts via an Anti-Corruption Layer and emits only the relationship facts necessary for downstream order creation, billing setup, inventory allocation, and engagement orchestration.