Check your builder CRM export before accepting the handoff

A builder CRM export needs matching identifiers, readable fields and intact relationships before you accept it for handoff. Compare meaning as well as row totals. This AgAI Labs worksheet proposes synthetic field tests, project links and evidence checks. Keep unresolved losses visible before anyone authorizes a vendor exit or migration.

What should an export preserve beyond contact rows?

Start the acceptance worksheet with a scope record. Name the source system, export settings, cutoff timestamp with timezone, included record types and responsible reviewer. Use private file references. Record which filters exclude archived, inactive or restricted records. Do not compare files drawn from different scopes as though their totals should agree.

A matching contact count proves only that the totals agree. Duplicate identifiers can hide missing contacts. A preserved contact row can still lose its notes, original source or project role. Count parsed records for each record type. Then compare the source and exported identifier sets for missing, unexpected and duplicate identifiers.

Include field definitions and allowed values beside those checks. Preserve permission status, evidence references and recorded exclusions without inferring permission from a populated address. Keep original source separate from later touches. Compare notes as text, including their boundaries and dates. The broader builder CRM guide explains system selection and setup.

This worksheet is a proposed practice for evaluating files. It does not authorize a real export, import, deletion, account cancellation or live migration. Keep raw exports private. Use synthetic records for the exercise below. The lead data ownership article covers the wider account handoff.

Which test records reveal damaged fields?

Create a fixture, meaning a fixed synthetic input with a written expected result. Copy this worksheet into a private review document. Add one row per field and test case. Leave observed results marked untested until someone inspects the actual file.

Use the builder CRM field dictionary to define each meaning before testing. An empty field may mean not collected. An explicit unknown value may mean someone checked but could not establish the answer. Those are example definitions. Use your documented definitions and preserve any difference.

The following CSV is fictional. The note occupies two physical lines inside one quoted field. It remains one logical record. Preserve CRLF record separators when reproducing this RFC-style fixture.

contact_id,project_id,note_text,lot_status,permission_status,occurred_at
00042,P-7,"Plan, revision ""B""
Review pending",,unknown,2026-10-28T09:15:00-04:00
00043,P-8,"No plan supplied",unknown,unknown,2026-10-28T13:15:00Z

RFC 4180, section 2 describes quoting fields containing commas, line breaks or double quotes. Embedded double quotes double inside quoted fields. It describes CSV syntax, not this builder worksheet. It does not define your blank values, identifier types or timezone policy.

Treat CSV as data. Use a parser or text viewer that does not evaluate cell content. Do not run formulas, macros or embedded instructions. Preserve an untouched copy before inspection. Verify leading zeros in parsed text, because quotation alone does not establish a field type.

How do you reconcile project and activity relationships?

Write a second worksheet for links between records. Record the relationship type, source pair of IDs, exported pair, expected role, observed result and evidence. Add an exception owner for every mismatch. Match stable IDs before considering labels. Project labels alone cannot establish identity.

In this fictional example, project P-7 relates to contacts 00042 and 00043. Contact 00043 also relates to project P-8. The CSV above carries one project reference per contact. It therefore omits the 00043-to-P-7 relationship. Two exported contacts still match two source contacts, but that agreement hides a lost link.

Require each exported relationship to resolve to its included parent records or a documented exclusion. Compare missing and unexpected pairs. Check relationship roles separately. A correct pair with the wrong role still changes the record's meaning. Do not merge contacts to force a match.

For history, compare activity IDs, parent IDs, recorded author references, timestamps and full text. Check earliest and latest activities and any edited notes. Preserve original source and later source events separately. For attachments, compare reference IDs, parent IDs, filenames and a private file inventory. A working reference does not prove the file itself arrived.

What must the provider confirm separately?

Ask the provider to identify its documented export paths for each required record type. Attach the documentation version and verification date to your scope record. Contacts, activity history and attachment files may require separate exports. Do not assume any vendor exports every record type.

Request written answers about archived records, deleted-record visibility, custom fields, relationship tables, note edits and attachment access. Ask how export timestamps and timezones work. Confirm whether attachment references expire and whether files require separate authorized access. Record unsupported items as gaps rather than guessing from the interface.

Ask how changes made after the cutoff are identified. A file created later may include a different state. Record each file's capture time and scope. Keep any later comparison separate from the accepted snapshot. Provider confirmation and local inspection answer different questions, so retain both.

Use a provider-answer record with these fields: question, affected record type, documentation reference, answer, verification date, unresolved gap and responsible owner. Keep unanswered questions open. These checks establish no new retention terms or cancellation rights.

What evidence supports accepting an export?

Use a numbered review process so another authorized reviewer can reproduce the decision from the same files.

1. Freeze the review scope. Record filters, cutoff, record types, fixture version and source dictionary.
2. Identify the files. Record private locations, filenames, sizes and checksums. Keep originals unchanged.
3. Compare identity. Reconcile parsed counts and ID sets for every included record type.
4. Inspect meaning. Complete each field test with expected values, observed values and evidence references.
5. Inspect relationships. Compare parent links, roles, history and attachment inventories.
6. Resolve exceptions. Record corrections or explicit exclusions with owners and reasons. Retest corrected files.
7. Record the decision. Name the reviewer, date, accepted scope, unresolved limits and supporting worksheet version.

Accept only the scope the evidence supports. Mark missing critical links, changed permission meanings or unavailable required history as held. A checksum identifies file bytes; it does not prove completeness. A passing fixture checks that example; it does not prove every record.

Keep the acceptance record with the private handoff documentation. Acceptance of files gives no permission to import them, change access or cancel a vendor. Those actions need separate decisions.