Flagging Invalid Rows

Flagging invalid rows marks each failing row with what is wrong, and how serious it is, instead of removing it. Errors block the row until fixed; warnings point out something unusual but let the row through.

Deleting bad rows loses data, and rejecting the whole file frustrates the user. Flagging is the middle ground: the user sees every problem in context, fixes what matters, and the import continues. The quality of the message decides whether they fix it themselves or contact support.

Give every check a level as well as a message, then summarize each row:

// Each check returns a message and a level, so warnings do not block the import.
const checks = [
  {
    field: "email",
    level: "error",
    message: "Not a valid email",
    test: (v) => /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(v),
  },
  {
    field: "phone",
    level: "warning",
    message: "No phone number",
    test: (v) => String(v ?? "").trim() !== "",
  },
  {
    field: "startDate",
    level: "error",
    message: "Start date must be a real date, today or earlier",
    test: (v) => {
      const d = new Date(v);
      return !Number.isNaN(d.getTime()) && d <= new Date();
    },
  },
];

const rows = [
  {
    id: 1,
    email: "ana@example.com",
    phone: "555-0100",
    startDate: "2025-01-15",
  },
  { id: 2, email: "ben@example", phone: "", startDate: "2025-03-01" },
  { id: 3, email: "cy@example.com", phone: "", startDate: "2099-06-01" },
  { id: 4, email: "di@example.com", phone: "", startDate: "2025-06-01" },
];

const results = rows.map((row) => {
  const flags = checks.filter((check) => !check.test(row[check.field]));
  return {
    id: row.id,
    status: flags.some((f) => f.level === "error")
      ? "error"
      : flags.length
      ? "warning"
      : "ok",
    flags: flags.map((f) => `${f.field}: ${f.message}`).join("; ") || "none",
  };
});
console.table(results);

Input

Output

• Error or warning. Only block on problems that will cause real harm. A missing optional field is a warning.
• Say how to fix it. "Start date must be a real date, today or earlier" is better than "Invalid date".
• Show the cell, not just the row. Point at the exact field so the user does not have to hunt.
• Let users filter. In a large file, a view of only the flagged rows is what makes fixing practical.

In Dromo, validators add errors to individual cells, and hooks can add messages with a level of error, warning, or info, shown in red, yellow, and blue. With enableNavigatingErrors turned on, users can filter errors by column, step through each one in a panel, and clear or replace the value inline. When the import finishes, rowsWithError and errors in the results metadata list whatever is left.

• Dropping Invalid Rows: Removing rows that fail validation, while keeping a record of why.
• Dynamic Data Validation: Validating data against rules or reference data that are loaded at runtime.
• Requiring Values: Making sure required fields contain a real value.

Flagging marks a row with what is wrong and keeps it so it can be fixed. Dropping removes it from the import. Flagging is usually better while a person can still fix the data, and dropping suits automated loads where the rejected rows are reported for later.

It names the field, shows the value, explains the rule in plain language, and says how to fix it, for example: Start date 2099-06-01 is in the future. Use today's date or earlier.