A staffing CRM data quality and technical debt playbook

A candidate merge can make a duplicate count look better while damaging placement history or an ATS connection. A mandatory field can improve completeness while encouraging recruiters to enter a placeholder. Data quality work succeeds when the operational record becomes more trustworthy and the source of the defect is addressed.

This playbook is an illustrative method for a Salesforce-based staffing business. It assumes that some records may be owned by an ATS, payroll system or managed package. Confirm those boundaries before editing identifiers, deleting history or replacing package behavior.

1. Start an issue log people can use

For each issue, record: affected object and population; evidence; operational consequence; likely source; accountable owner; proposed containment; repair method; verification; recovery method; and next decision date.

Populated examples:

• DQ-01, duplicate candidates: two CRM contacts appear to represent one person, but their ATS identifiers differ. Consequence: submissions and history are split. Owner: recruitment operations with the integration owner. Containment: flag for review and prevent automated consolidation. Evidence required: identity confirmation and source-system crosswalk.
• DQ-02, missing assignment rate dates: active assignments contain current rates without an effective period. Consequence: historical reports may use the wrong terms. Owner: finance operations. Containment: mark affected calculations incomplete. Repair: recover authorized rate history from its source and reconcile a sample before bulk loading.
• DQ-03, conflicting status updates: an integration changes an assignment back to Active after a user closes it. Consequence: unreliable active-work reports. Owner: integration lead. Containment: capture the conflicting event and review field ownership. Repair: define permitted transitions and source precedence, then replay only the approved events.

A duplicate percentage alone cannot tell you which of these deserves attention first.

2. Prioritize consequence, recurrence and reversibility

Use a simple decision order:

1. Contain active exposure or incorrect operational/financial decisions. Escalate sensitive or regulatory questions to the responsible owner.
2. Fix the mechanism creating new errors before running a large cleanup.
3. Repair records blocking current work, using a tested process.
4. Improve lower-risk historical completeness only where there is a defined reporting or retention need.

For each proposed repair, mark consequence High/Medium/Low, recurrence Ongoing/Stopped/Unknown and reversibility Tested/Partial/Unknown. High-consequence or unknown-recovery work needs a more careful test and approval path. Do not multiply subjective scores into a precise-looking business case without explaining the judgment behind them.

Old records are not automatically disposable. Retention obligations, contractual history, reporting and legal holds may require preservation. Have the appropriate business and legal owners decide the policy; this guide does not define a universal retention period.

3. Trace the defect to its source

Follow an example record back through the form, import, integration or manual process that created it. Preserve the source identifier and timestamps where available. Ask whether the data was missing at source, transformed incorrectly, overwritten later or collected too early in the workflow.

For DQ-01, two valid ATS people may share a family email address. Exact email equality is therefore a candidate match signal rather than conclusive identity. Conversely, one person may legitimately use several addresses. Keep uncertain pairs in review.

Where an integration uses an external ID for upsert, understand the actual contract. Salesforce's REST resource creates or updates based on the match; multiple matching values produce an error. An external ID value is not itself a business identity policy, and an integration must handle ambiguous or missing matches explicitly. Salesforce external-ID upsert documentation

4. Rehearse a merge before touching the live pair

A useful merge worksheet includes:

• Identity decision: why these records represent the same person, and who approved it.
• Survivor: which record and system identifiers remain authoritative, with a field-by-field decision for conflicts.
• Relationships: submissions, assignments, activities, files, campaigns, account relationships and package-specific records.
• Attribution: original source, recruiter credit, consent or communication preferences, and any restrictions on use.
• Integration effect: which connected systems need a crosswalk or notification and which must not create the retired record again.
• Evidence: pre-change values, relationship counts and secure backup references.
• Recovery: the exact restore or corrective procedure already tested, including its limits.

Salesforce documents exceptions to Contact merge behavior: related items may move with exceptions, only the primary record's Chatter feed is retained, and portal-user relationships can be affected. The non-primary contacts move to the Recycle Bin, but that does not make the full merge a simple reversible transaction. Read the relevant object and package documentation. Contact merge considerations

Take a permitted backup or snapshot sufficient for recovery and test restoration in an appropriate environment. A CSV of visible fields may omit relationships, files or restricted data. Conversely, exporting everything creates unnecessary exposure. Use the minimum authorized data with controlled access.

5. Execute a bounded repair and reconcile it

For the illustrative candidate pair, first resolve which ATS identity is correct. Preserve an old-to-surviving-ID crosswalk. Test a representative copy, verify expected relationship counts and inspect actual submissions and placements, not just totals.

During the agreed repair window, control competing writes through the established change process. Apply the approved field choices, reconcile integrations and confirm that an ordinary subsequent source update targets the survivor. A successful merge screen is only the beginning of acceptance.

Stop if a financial relationship disappears, an access boundary changes unexpectedly or an integration recreates the duplicate. Investigate before expanding the batch. Restore or correct through the tested procedure rather than improvising a second mass update.

6. Retire the debt that allowed it to recur

For each issue, keep one enduring owner and a closure test. DQ-03 closes only when the status ownership contract is implemented, replay tests pass and new events no longer reverse valid closures. “We cleaned the records” is insufficient if the next nightly sync reintroduces the problem.

Track new defects per intake source, unresolved age and the operational consequence they cause. Separate active-work quality from historical completeness. Review validation failures for signs that the workflow asks for information before people can know it.

Use controlled releases and risk-appropriate tests for structural changes; Salesforce's application-lifecycle guidance supports documented release artifacts and deliberate testing rather than risky direct production changes. Salesforce deployment best practices

Start with one repeatable defect

Discuss staffing data quality with Gosai Digital. Bring an anonymized issue-log row, the systems that write the affected fields and the report or handoff it disrupts. That supports a repair plan with clear evidence and recovery boundaries.