Skip to main content

Fix Rejected Rows and Reprocess

Use this recipe when DFS rejects source rows because values, schema, mapping, or source context need correction.

The goal is to fix the source of the problem, preserve review evidence, and reprocess rows only when the source can be reread safely.

Outcome​

At the end of this workflow, you should have:

  • rejected row reviewed;
  • reason understood;
  • source owner identified;
  • upstream data corrected when needed;
  • row acknowledged or marked fixed in source;
  • reprocess result recorded;
  • accepted and rejected counts checked.

Step 1: Open the rejection queue​

Go to:

Data Integration > Review Queue

Open the rejection queue area when rejected raw rows need source repair.

Filter by:

  • state;
  • source;
  • dataset;
  • connector;
  • reason;
  • correlation ID when available.

Step 2: Inspect the rejected item​

Open the item detail and record:

  • source;
  • connector ID;
  • dataset ID;
  • source file;
  • source cursor;
  • row index;
  • correlation ID;
  • raw payload;
  • reason;
  • field errors;
  • created time.

This information helps the source owner locate the exact upstream record.

Step 3: Classify the cause​

Common causes:

  • missing required field;
  • invalid timestamp;
  • value outside expected range;
  • unknown asset ID;
  • unexpected unit;
  • malformed CSV row;
  • changed API response shape;
  • database column type change;
  • duplicate record;
  • source record outside the accepted time window.

Write a short note that a reviewer can understand later.

Step 4: Acknowledge the row​

Use Acknowledge when the issue has been reviewed and source repair is being handled or intentionally deferred.

Include:

  • who owns the source fix;
  • what needs to change;
  • expected follow-up;
  • reason for deferring when applicable.

Step 5: Fix upstream source data​

Fix the source before reprocessing whenever the raw source record is wrong.

Examples:

  • correct asset ID in the source system;
  • add missing timestamp;
  • correct unit label;
  • repair malformed CSV row;
  • update source query;
  • update connector mapping;
  • update transformation expression.

Keep the fix in the source system or approved integration layer so future syncs stay consistent.

Step 6: Mark fixed in source​

After the upstream fix is complete, use Mark fixed in source.

Add a note with:

  • source change;
  • source owner;
  • time of fix;
  • related connector or mapping change;
  • expected reprocess behavior.

Step 7: Reprocess​

Use reprocess when connector provenance exists and the source can be reread.

Before reprocessing, confirm:

  • connector still exists;
  • source record can be reached;
  • source credentials are valid;
  • mapping rule has been corrected;
  • source reread preserves downstream dataset uniqueness;
  • reviewer understands the expected result.

Run reprocess and wait for the result.

Step 8: Confirm result​

After reprocess:

  • review replay result;
  • check accepted count;
  • check rejected count;
  • check correlation ID;
  • inspect sync history;
  • inspect dataset preview when the row should appear there;
  • record any remaining source issue.

When to stop and escalate​

Escalate to an administrator or engineer when:

  • the connector is unable to reread the source;
  • raw payload is missing;
  • source cursor is ambiguous;
  • mapping logic needs code-level change;
  • reprocess repeatedly creates duplicates;
  • rejected rows indicate a schema change across many records.

Next step​

Use Sync History to confirm the next connector run behaves as expected.