15.2 Data Management Strategy, Data Quality & Integration Governance

15.2 Data Management Strategy, Data Quality & Integration Governance

Exam Focus: The official objective is "Given a set of business data requirements, design data management strategy and process to ensure high data quality and a seamless integration." Salesforce bundles quality and integration into one objective deliberately: in government they are the same failure. A duplicate constituent record created by an unmatched inbound integration is simultaneously a data-quality defect and an integration defect, and its consequence is a person receiving two determinations, or none.

---

Why Data Quality Is a Legal Matter Here

Commercial dirty data costs a wasted mailing. Government dirty data produces a wrong determination on a legal entitlement. Consider the consequences of a single duplicated constituent:

• The household appears twice, so means-tested eligibility is computed against half the income and a benefit is overpaid — creating a recovery action against a vulnerable person.
• An enforcement history splits, so a repeat violator presents as a first-time offender and receives the wrong penalty tier.
• A records request or appeal returns an incomplete file, which is itself a compliance failure.
• Reporting to a federal funder understates or double-counts served individuals, putting the appropriation at risk.

That is why the strategy has to be preventive. Cleanup projects treat symptoms; the objective asks for a process that keeps quality high.

---

Element 1: Declare the System of Record, Field by Field

The foundational artifact is a table naming, for every shared field, which system owns it and which merely displays it.

Two rules follow, and both are testable:

1. A field has exactly one master. "Both systems can update it" is not a design; it is a defect scheduled for later.
2. Reference data is read-only in Salesforce. If the assessor system owns parcel data, users must not be able to edit it in Salesforce — otherwise the two diverge and nobody can say which is right.

---

Element 2: Migration Strategy for Legacy Government Data

Agencies migrate from mainframes, county systems, and spreadsheets, carrying decades of history under a records schedule that forbids simply discarding it.

---

Element 3: Prevent Duplicates at the Front Door

Public Sector Solutions constituent data lives on Person Accounts, and duplicate prevention has to be designed for them explicitly.

• Matching rules define what "the same person" means for this agency. Name plus date of birth plus partial identifier is typical; name alone is not, because government populations contain many exact name collisions.
• Duplicate rules decide what happens on a match: block, or alert and allow with a reason. In benefits intake, blocking is usually right; in emergency response intake, alert-and-allow is right, because a responder cannot be stopped mid-crisis.
• Inbound integrations must run through the same matching logic. The most common source of duplicates is not a person typing; it is an interface inserting records that never checked for an existing match. Give integrations an idempotent upsert keyed on a stable external identifier.
• External identifiers matter more than they look. A unique external ID field on the constituent record is what makes upsert safe and re-runnable, and re-runnability is what saves an integration outage from becoming a duplication event.

Validate at the point of entry

Quality is cheapest at the moment of capture:

• OmniScript validation on the constituent-facing form — format, ranges, and cross-field consistency — so the person fixes it while they are still there;
• required fields and validation rules on the object for staff-entered data;
• picklists over free text for anything that will be reported on or used in a rule, because a rule cannot reason over free text;
• Document Checklist Items to make completeness explicit rather than discovered late.

---

Element 4: Choose and Govern the Integration Pattern

Select from the requirement's latency and volume, not from familiarity.

Governance rules that keep integrations from degrading data quality:

• Authenticate through named credentials, never through credentials embedded in code or custom settings.
• Make every inbound interface idempotent — a replayed message must not create a second record.
• Handle errors visibly. A silently failing nightly interface produces a slow, invisible divergence that is discovered by an auditor. Integration Procedure error handling should record the failure somewhere a human is accountable for.
• Log what was received. For determinations that can be appealed, the agency must be able to show the value it relied on at the time, not the value the external system holds today.
• Respect the Government Cloud boundary. An integration leaving a Government Cloud org must be assessed against the data classification, not assumed to inherit the org's authorization.

---

💡 Real-World AP-222 Exam Scenarios & Case Analysis

Scenario 1: Duplicate Households in a Benefits Program

A state benefits agency finds that 9% of its constituent records are duplicates. Investigation shows most were created by a nightly interface from a legacy county intake system that inserts a record for every household it sends. Two households have received duplicate benefits, triggering recovery actions.

What is the strategy?

• Treat this as an integration defect first: convert the nightly insert to an idempotent upsert keyed on a stable external identifier so a re-sent household updates rather than duplicates.
• Define matching rules for Person Accounts that reflect how the agency identifies people — not name alone — and enforce duplicate rules in the intake path.
• Run a deduplication remediation using those same rules, with merge decisions reviewed where a benefit determination is affected, because merging records that carry legal determinations is not a purely technical operation.
• Declare the system of record for household composition so the county system and Salesforce stop competing for it.

Scenario 2: Eligibility Against External Wage Data

An eligibility determination must use verified wages from a state wage verification service. Wages change; determinations are appealable for 60 days.

How should this be designed?

• The wage service is the system of record; wages are read-only in Salesforce, so a caseworker cannot edit them into agreement with a claim.
• Retrieve at determination time with an Integration Procedure HTTP action over a named credential — a stale nightly copy would produce determinations against data the agency cannot defend.
• Persist the retrieved value and its retrieval timestamp with the determination. When the appeal arrives 45 days later, the agency must show the figure it actually relied on, not today's figure.
• Run the determination in Business Rules Engine so the rule version and the decision output are inspectable alongside the input.

Scenario 3: Mainframe Retirement With Thirty Years of Records

A licensing agency is retiring a mainframe holding 30 years of licence history. The records schedule requires retention of some categories for the life of the licensee. The project team proposes loading everything into Salesforce.

What should the architect advise?

• Migrate active licences and the history needed for operations, open appeals, and the records schedule; archive the remainder in an accessible archive rather than inflating the org with records nobody queries.
• Cleanse in staging, not after load, so corrections happen outside production change control.
• Deduplicate during migration with the production matching rules, which proves those rules on real data before go-live.
• Reconcile with counts and sampled record-level comparison, signed off by the business owner, and rehearse the load at full volume with a timed rollback before cutover.