How do I spot rows that failed to import because required fields were missing?

Start with two checks: what the import process reported, and what your field rules require. Look for a rejected-rows file, import summary, error log, or other result the system provides. Do not assume every row absent from the destination failed for the same reason: a row might have been filtered, skipped, or rejected for a different issue. Compare counts or a stable row identifier in the source and destination if those are available.

Next, write down the fields that must have a value for this particular import. A blank in an optional notes field is different from a blank in a required account identifier. Power Query’s Column quality profile can show valid, error, empty, or unknown values and their proportions; its default profile covers the first 1,000 rows, with an option to profile the entire dataset. The profile does not decide whether an empty value violates your requirements, so check blanks against your own rules. [S1]

Make a small field-rules list before filtering. For each field, specify whether it is required, what counts as empty in your file, and any allowed exception. For example, a blank in “Secondary phone” might be permitted, while a blank in “Record ID” might need review. Treat spaces-only cells and placeholders such as “-” as possible blanks only if your import rules say they should count that way; don’t silently change their meaning.

Then create a check for each required field and mark a row when any required value is empty under those rules. Keep the original value and note which field triggered the flag. This is a missing-value check, not an error check: a cell containing an actual error, such as a failed conversion, is a separate issue. In Power Query, Keep errors can isolate rows with cell-level errors, but it does not find rows missing required fields; those need a separate blank check. [S2]

Create a correction queue as a separate copy or output of the flagged rows. Include the original row identifier (or source file and row reference), the fields that failed, a short reason, and a status such as “Needs information,” “Ready to retry,” or “Resolved.” Preserve the untouched source values in that queue; make corrections in clearly identified fields so someone can compare before and after.

A useful queue record might look like this:

Source row: [row identifier] | Record ID: [blank] | Secondary phone: [blank] | Reason: Record ID required | Status: Needs information

Do not delete rejected rows just because the import did not accept them. If the system supplies an error report, retain or link it with the queue, while avoiding unnecessary copies of sensitive information. The exact export, retry, and audit options depend on the import tool, so check its available controls rather than assuming a particular feature exists.

Retry only the corrected rows when your tool allows it, rather than re-importing the whole source without checking for duplicates. Before retrying, rerun the required-field checks and confirm each queued row has moved to a status that means it is ready. After the attempt, compare the retry results with the rows you submitted: note which were accepted and which still need attention, and update their queue statuses.

For example, if a batch has 12 flagged rows and you correct 9, your check is not simply whether the retry finished. Confirm that the 9 submitted rows have a recorded outcome and that the other 3 remain in the queue with a reason. This is a tracking example, not a claim about any particular import tool. Keep the original rejection information until you have verified the outcome; the available confirmation detail depends on the system.