Data Project Walkthroughs

A credible data project begins with the records, rules, and acceptance criteria that apply to the organization commissioning the work. An unattributed result from a different database cannot establish what will happen in yours. These walkthroughs therefore focus on the evidence a project should create: preserved inputs, explicit transformations, reviewed exceptions, and reconciled outputs.

Each guide below addresses a different job. Some projects repair an existing system; others add fields, prepare a migration, or create a repeatable maintenance process. The guides explain what to inspect and what to ask for without presenting invented companies, database sizes, turnarounds, or outcomes as customer proof.

Start with a measured baseline

Export a representative sample that includes difficult cases alongside clean records. Preserve the export and record its source, date, object type, filters, and row identifiers. Define the population eligible for each test so a rate or count has a clear denominator. An enrichment matched share, for example, is meaningless if rejected input rows disappear from the denominator.

Profile the sample for nulls, duplicates, conflicting identifiers, unexpected values, and date coverage. The output is a file-specific baseline. It should describe the supplied file and the rules used to inspect it. Any later comparison should use the same definition or explain the change.

Write acceptance rules before the full run

For each requested transformation, state what qualifies as accepted, rejected, or sent to review. A proposed duplicate merge might require agreement across several stable identifiers. An appended job title might require a public source, a capture date, and a role taxonomy. A standardized company name might preserve the source value alongside the normalized form.

Acceptance rules also define who decides ambiguous cases. The vendor should not silently choose how to resolve a conflict that changes ownership, consent status, customer history, or an account relationship. Name the reviewer and return enough context for that person to make a decision.

Require row-level provenance

An enriched or changed field should be traceable to its source and processing date. Derived fields should identify the rule or model version that produced them. If several sources disagree, the delivery should show the conflict and the survivorship decision rather than presenting one value as self-evidently correct.

Provenance is useful beyond auditing. It lets the team refresh fields selectively, measure which sources create disputes, and avoid replacing a reviewed value with a weaker automated value during the next run. It also makes sample review faster because the reviewer can inspect the exact evidence behind the returned field.

Review both changes and misses

A quality sample should include records the process changed, records it left alone, low-confidence candidates, and rejected candidates. Reviewing only successful matches omits false negatives and difficult exceptions. Sampling should cover major source systems, object types, regions, and data conditions represented in the full file.

Log each disputed row with a reason. Update a rule only when the change generalizes, then rerun the affected population and repeat the sample. One-off spreadsheet edits may repair individual rows, but they do not improve the repeatable process.

Make delivery reversible

Keep untouched inputs, stable row identifiers, transformation logs, proposed merges, rejected records, and final outputs. Test the destination import on a small batch. Confirm relationships, ownership, activity history, automation behavior, and needed fields before expanding the load.

After import, reconcile counts between the approved files and the destination system. Record exceptions and retain the rule set with the delivery. An import job's success message is one check; the records and relationships must also match the approved output. Review current destination behavior in the Salesforce duplicate-management documentation or HubSpot merge documentation when either platform is in scope.

Compare providers with the same sample

Before comparison begins, publish a compact evaluation sheet. List the objects in scope, fields requested, source-date expectations, status labels, and needed output columns. Add the review method for proposed merges and a place to record disputed rows. Give the same sheet to each participant so a polished presentation cannot substitute for comparable returned data.

Keep business recommendations separate from row-level observations. The returned file can show which records matched, which values changed, and which exceptions remain. A recommendation may then explain how those observations affect sequencing or scope. Separating the layers lets reviewers accept the data work while challenging a recommendation, or reject a weak field without discarding the rest of the delivery.

Document the handoff owner for each artifact. Operations may approve field mappings, system administrators may approve import behavior, and campaign owners may approve eligibility rules. A named owner and dated decision prevent unresolved exceptions from becoming silent defaults during implementation. The final handoff should state what remains unknown and which action would resolve it.

Retain that evaluation record with the approved delivery so the next review begins from evidence instead of reconstructing earlier decisions.

Give each provider the same representative rows, requested fields, status definitions, and export requirements. Ask for the current written scope and proposal. Compare the returned rows, provenance, exceptions, and review workflow. A broad vendor claim is less useful than evidence showing how the provider handled the exact records your team supplied.

Do not treat a hypothetical walkthrough as a forecast. Your file condition, system behavior, field requirements, review capacity, and approval process determine the work. The sample should establish the baseline and surface the decisions needed for a scope-specific plan.

How should you plan a data project?

Begin with preserved source records, explicit eligibility and acceptance rules, a representative review sample, and a reversible delivery plan.