An Approved Outreach Report Export Was Truncated: Recall and Reissue the Missing Rows

The approved source can be complete while the delivered file is not. That distinction matters because a recipient may make a targeting, suppression, follow-up, or reporting decision from the delivered file, not from the source you approved.

Start by freezing both artifacts. Keep the approved source, the delivered export, the export settings, the delivery location, and the recipient list. Do not overwrite the first delivered file, even after you create the correction.

For LinkedIn outreach reporting, compare stable row identifiers first. A count mismatch tells you that a gap exists. Identifier comparison tells you which records disappeared and where the truncation starts.

• Record the approved row count and a hash of the approved exportable population.
• Record the delivered row count and a hash of the delivered file.
• List the omitted identifiers and the first and last boundary identifiers.
• Preserve the filters, sort order, columns, time range, and export format used for delivery.

How do you prove that the approved source was complete?

Use the same query and filter state with the same column set that produced the approved population. Export or query that population again only for verification, then compare it with the archived approved evidence. A new live query can change after the incident, so it cannot replace the original approval record.

Check whether the delivery path imposed a visible limit. Power BI documents different limits by format, including a maximum of 30,000 rows for CSV exports and 150,000 rows for standard XLSX exports. Its export can also reflect filters, permissions, row-level security, and the selected summarized or underlying-data option. Microsoft Learn

A row count alone does not prove completeness. Duplicate records can make a truncated file match a count target. Compare a stable key set, such as an internal or campaign-member ID, or another identifier that is unique within the approved population.

Which export limits or settings could have cut the file?

Check the reporting tool before blaming the source. In Power BI, exports can be summarized or underlying data, and the visible export depends on permissions and filters, as well as report design. The documented CSV export limit is 30,000 rows, and the standard XLSX export limit is 150,000 rows. Microsoft Learn

Looker separates the current result table from all results and custom row selections. Its documentation says that current-result exports follow the content row limit, while all-results availability depends on permissions, query complexity, database support, and streaming. Google Cloud Documentation

Spreadsheet software can create a false sense that every record arrived. Excel supports up to 1,048,576 rows on a worksheet, but that capacity does not prove the upstream export contained every approved record. Microsoft Support

• Confirm whether the export used the full result set or a selected view with a custom row limit.
• Compare summarized data with underlying data only when both are authorized and relevant to the intended report.
• Check filters, date ranges, row-level access, hidden rows, and selected columns.
• Open the file with a CSV-aware parser before relying on a spreadsheet display.

How should you inspect the delivered CSV or spreadsheet?

Parse the delivered file with a tool that understands the file format. CSV records may contain commas or quoted fields with line breaks, so counting physical lines can produce the wrong row count. RFC 4180 describes quoted fields and optional headers for the common CSV format. RFC Editor

If the source came from a database export, retain the exact export query or command. PostgreSQL documents that `COPY TO` can export a table or the results of a query, and that successful completion reports the copied row count. PostgreSQL Global Development Group

Use a deterministic normalization rule before hashing. For example, keep the header decision and field order fixed; normalize line endings if your process permits it, then hash the resulting bytes. Do not compare hashes from two files that differ only because one exporter reordered columns unless the comparison rule accounts for that difference.

Who needs the recall, and which decisions need review?

Build the recipient list from actual access, not the intended distribution list. Include direct recipients, shared-drive locations, dashboard downloads, automation destinations, and anyone who received a forwarded copy.

For each recipient, ask one concrete question: did you use the delivered file to make or support a decision? Record the decision. Record its owner and time. Note whether it can be reversed. If the answer is unknown, leave it marked unknown until the recipient confirms.

Do not quietly replace the file and assume the problem is closed. The recall message should name the incorrect file and state that rows were omitted. Identify the replacement location and ask recipients to stop using the old copy.

• Target selection or exclusions based on the truncated population.
• Outreach sequencing or follow-up work based on missing records.
• Performance totals, weekly reporting, or client-facing summaries.
• Any import into another system that may have preserved the incomplete set.

What should the corrected export include?

Issue one replacement file with a clear version label and delivery timestamp. State its row count and content hash. Include the approved filter definition and the stable-key reconciliation result. The point is to let a recipient verify the correction without reconstructing the incident.

Send the correction to every confirmed recipient of the truncated export. If a recipient used the old file for a decision, include the specific decision that needs review. Keep the original incident record alongside the corrected file.

For a comment-led outreach operation, keep the correction focused on the report population. Do not infer platform allowances, safe limits, or account status from the incident. The operational lesson is export verification, not a claim about LinkedIn limits.

How do you prevent the next export from losing rows?

Put the check before delivery. The export process should compare the approved population's stable identifier set with the delivered file's stable identifier set and fail closed when they differ.

If a platform has a documented row limit, split the export intentionally before it reaches that limit. Name each part. Record its row range and hash. Then verify that the union of all parts equals the approved population.

Use the Well Met method to keep reporting tied to real outreach activity, then keep the verification record with the report. If the report informs spend or planning, the recipient needs evidence that the file is complete before acting on it.

• Generate the approved key set and expected row count.
• Generate the delivered key set and delivered row count.
• Fail delivery when either comparison differs.
• Require a reviewer to confirm the incident record for exceptions.