Build the queue as a data-stewardship workflow, not a pile of exceptions: define which conflicts need a decision, route each case to someone with the right expertise and authority, show the evidence behind competing records, and preserve the outcome and its reasoning. Automate clear, low-risk cases; involve people when matching is uncertain or an incorrect choice could cause meaningful harm.
What belongs in a human review queue?
A queue case should make four things clear: what records disagree, what kind of conflict was detected, why automation did not resolve it, and what decision the reviewer can make. For example, two identifiers may point to different entities, two systems may provide incompatible values, or a matching process may find several plausible duplicate candidates.
As an Amazon Associate I earn from qualifying purchases.
Distinguish a genuine disagreement from missing data, stale values, schema differences, or a known transformation. Those conditions may need different actions—such as requesting an update or fixing a mapping—rather than choosing one source value over another. IDhub’s curator documentation illustrates a queue that records conflict types, review requirements, reasons, identifiers, and resolution actions: IDhub Audit & Resolution Tables.
At minimum, give each case a stable identifier and record the affected entity and fields, competing values, source identifiers, available timestamps or versions, the detection rule, the reason for review, and the requested decision. Treat this as a design pattern, not a universal schema: fields should reflect your data and decisions.
#1 Best Overall
When should automation hand a case to a person?
Use documented rules to resolve cases that are clear and low risk. Send a case for review when matching confidence is too low, multiple candidates remain, source evidence conflicts materially, or a decision has consequences that justify human judgment. SAP Information Steward’s match-review guidance describes manual review for possible duplicate groups that automated processing rejects because confidence is insufficient: SAP Match Review (Information Steward 4.3 SP2).
Set priority according to how your organization uses the data. Useful considerations include downstream impact, urgency, reversibility, and whether the conflict blocks an important process. These are local decision dimensions, not a universal scoring formula. The UK Government’s Data Quality Issues Framework supports identifying and prioritizing issues; the broader Government Data Quality Framework emphasizes fitness for purpose and attention to user needs and critical data. Neither provides standard weights, queue limits, staffing ratios, or response deadlines for this workflow.
How should cases be routed and decided?
Assign each conflict type to a role that has the knowledge to assess it. A data steward might resolve a question about definitions or source ownership; a domain owner may be needed for subject-matter judgment. Specify who may decide, who must approve consequential merges, and who handles disagreements. SAP documents reviewer and approver roles in its match-review workflow. SNOMED International describes independent review followed by agreement or adjudication when reviewers disagree: SNOMED International: Mapping and review approach.
Recommended Free Tools
Make the available outcomes explicit. Depending on the conflict, a reviewer may:
Rank #3
- Accept a value from one source, using a documented rule for why that source is appropriate for this field and use.
- Retain both values with a clear distinction, rather than forcing a false single answer.
- Merge records or mark them as distinct.
- Request more evidence, escalate the case, or return it to the source owner for correction.
For consequential or hard-to-reverse actions, require a second reviewer or an approval step where appropriate, and make reversal possible when the system allows. A single source should not be presumed authoritative in every domain: authority can depend on the field and intended use.
What evidence should the reviewer see?
Show the competing records side by side, with the fields relevant to the decision, source identity, timestamps or versions when available, and the matching or transformation context. State why the case entered the queue and present the permitted actions. Provide enough source evidence to verify a claim without making reviewers reconstruct the case across unrelated systems; avoid an undifferentiated data dump.
If resolution creates a canonical or “best” record, keep field-level provenance so users can see which source supplied each resulting value. SAP’s match-review documentation describes a lineage table that traces fields in the resulting best record to their origins.
How do you preserve the decision for audit?
Record the chosen outcome, reviewer identity or role, decision time, rationale, evidence considered, and any changes made. Retain the original values and source references so the decision can be audited or revisited. If a reviewer creates a merged record, preserve lineage from its fields to the source fields. IDhub documents audit and resolution tables for curator actions, while SAP describes source lineage for best-record fields.
Best Value
How do you improve the process over time?
Monitor the queue as both an operational workflow and a signal about upstream data quality. Locally useful measures include waiting time, handling time, age of unresolved cases, volume by conflict type, and escalation frequency. These are management measures to choose for your needs, not published benchmarks.
Look for recurring patterns by source, field, and detection rule. A run of similar conflicts may call for correcting source data, clarifying ownership, or changing a transformation or matching rule—not just resolving each case individually. The Government Data Quality Framework recommends documenting issues, monitoring quality, and using root-cause analysis to address problems at their source. SAP also recommends monitoring review progress and coordinating matching to reduce groups that require manual review.
Periodically check whether the trigger is sending routine cases to people or leaving consequential cases waiting. The aim is not to maximize automation or the number of reviews; it is to send the right cases to people, preserve defensible decisions, and reduce repeat causes.
Choosing the right level of review
Choose a resolution path for each conflict class by considering decision risk and reversibility, the quality and authority of available evidence, expertise required, likely manual volume, downstream impact, audit and lineage needs, and how quickly disagreement can be escalated. Clear low-risk cases may be automated; ambiguous cases may need one qualified reviewer; consequential disagreements may warrant independent review and adjudication; cases lacking adequate evidence may need to wait for more information. SNOMED’s guidance illustrates independent review with adjudication, while SAP documents a reviewer-and-approver match-review process.
These controls matter especially when integrating systems with different histories, terminology, or standards. NHS England’s Canonical Data Model describes that integration challenge, but does not prescribe a queue design. A shared model and a human workflow serve different purposes: standardization can reduce avoidable disagreement, while review handles the cases that remain.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
