MDM Steward Queue

The Steward Queue is the review surface for uncertain identity matches. Resolver tasks can propose that an incoming source record belongs to an existing golden record. A steward reviews the candidate before the alias becomes confirmed.

Use this queue for identity decisions. Route generic data-quality errors through the data-quality and rejected-row workflows.

Before you start

Confirm:

• dfs:read access to view candidates;
• dfs:write access to approve or reject candidates;
• source context for the systems being compared;
• authority to decide whether two records represent the same real-world object.

Open Steward Queue

Go to:

Data Integration > DFS Pro > Steward Queue

Filter by entity type and status.

Statuses:

Status	Meaning
Pending	Candidate needs steward decision.
Approved	Candidate was accepted and the alias was confirmed.
Rejected	Candidate was rejected and recorded for future resolver runs.

Review flow

Use the queue as a controlled worklist. Each decision should leave enough context for the next resolver run, the downstream data owner, and the project handoff record.

Review a candidate

1. Select Review.
2. Compare the incoming source record with the candidate golden record.
3. Review similarity score.
4. Review field differences.
5. Check source evidence outside the score when needed.
6. Approve only when both records represent the same real-world object.
7. Reject when the pair describes different objects or the evidence is insufficient.

Key fields to compare:

Field group	What to check
Source identity	Source system, source ID, object type, and source owner.
Physical identity	Serial number, equipment code, asset tag, station, or location.
Descriptive fields	Name, class, model, vendor, and free-text description.
Time validity	Effective period, replacement date, commissioning date, or retired status.
Existing decisions	Active aliases, rejected pairs, merge history, and split history.

Treat the score as a sorting and triage signal. The score helps find likely matches; the steward decision should be based on source evidence.

Approve a candidate

Approve when the source ID should become an alias of the candidate entity.

Approval creates or updates the cross-source alias and marks the candidate as approved. Downstream fusion or reporting should be revalidated if the identity affects active outputs.

After approval:

1. Open the master entity.
2. Confirm that the new source alias is active.
3. Check whether the alias has the expected valid-from date.
4. Re-run or refresh the downstream fusion task that depends on the entity.
5. Record the decision in the handoff note when the alias affects production reporting, AI Agent evidence, or Inspector records.

Reject a candidate

Reject when the candidate is wrong or cannot be verified.

Use a short note when the reason will help future reviewers. A rejected pair is recorded so future resolver runs can suppress the same false match.

Good notes:

• Different physical device; similar name only.
• Reused source ID after replacement; historical period must be checked.
• Source record lacks serial or location evidence.

After rejection, check whether the source record should become a new entity, remain unmatched, or wait for source correction. Rejections should reduce repeated review work rather than hide a data-quality problem.

Queue operating model

For production use, define a simple queue policy before the resolver is scheduled:

Policy item	Recommended decision
Owner	Name the data steward group responsible for each entity type.
Review frequency	Review after each resolver run during onboarding; move to a regular cadence after volume stabilizes.
Escalation	Send candidates with missing source evidence to the system owner, not to a generic backlog.
Aging threshold	Track candidates that stay pending beyond the agreed review window.
High-impact entities	Require a second reviewer for entities used by production reports, work orders, or AI Agent workflows.

Use batch review only for low-risk candidates that share the same evidence pattern. Avoid batch approval when serial, location, replacement history, or source ownership differs across rows.

Decision guidance

Signal	How to treat it
Same stable source ID from a trusted system	Strong evidence, but confirm entity type and time period.
Same display name only	Weak evidence. Check location, serial, asset class, or source owner.
Close timestamp and similar fault text	Useful for event candidates; asset identity still needs source evidence.
Conflicting location or serial	Usually reject or split after review.
Missing key fields	Keep pending or reject with note until the source is corrected.

Validation checklist

• Pending candidates are reviewed by someone who understands the source systems.
• Approvals create the expected alias on the golden record.
• Rejections include a note when ambiguity is likely to recur.
• High-impact identity changes are communicated to downstream workflow owners.
• Review counts are included in handoff notes.
• Aging pending candidates have an owner and next action.
• Approved aliases are reflected in the next downstream refresh.

Next step

Use Merge, Split, and Re-Point when the existing identity structure itself needs correction.