CRM and support exchange operations workshop / 6 MIN READ
Make an import preserve, replace or append exactly what was intended
A before/input/expected-after mutation ledger for already identified records, covering omission or blank, explicit replacement, multi-value append and unsupported clearing requests.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-07
An import is a set of proposed record changes, not merely a file containing acceptable values. Review what each row will preserve, replace, append or leave untouched before treating a successful upload as a successful correction.
What you will leave with: A before/input/expected-after mutation ledger for already identified records, covering omission or blank, explicit replacement, multi-value append and unsupported clearing requests.
Use this when
- A bulk file updates existing records rather than creating a new dataset.
- Blank or multi-value cells could preserve, replace or append differently than intended.
Not identity matching, generic CSV formatting or permission to clear or import live data.
Declare the mutation before formatting the cell
HubSpot’s Format import files guidance, checked 7 November 2026, says blank cells do not clear existing values. It also distinguishes multiple-checkbox replacement from append syntax and requires the relevant option definitions. Those import semantics are not universal across platforms or other write methods. The acceptance exercise begins with already identified synthetic records.
For every field in the proposed update, write the intended operation in plain language. Is the team supplying a complete replacement, adding one membership to an existing set, or making no statement because the source lacks knowledge? Keep intentional removal separate from absence of information. Otherwise an innocent empty spreadsheet cell can be interpreted as either a deletion request or a preservation request without anyone noticing the disagreement.
Construct a before-input-after truth table
Create rows containing a stable fictional record identifier, existing value, proposed input, intended operation and expected final value. Include a populated scalar, an empty scalar and a multi-value field with existing members. Give each row a short reason so a reviewer can tell whether the input represents new evidence or merely a different formatting choice.
Use the destination’s actual import semantics to determine whether the proposed file can express the intended operation. If clearing is unsupported through that path, mark the row as not executable by this import. Do not invent a magic deletion string or switch to a different write method without separate review. A tool’s acceptance of a cell does not prove that the business asked for the resulting state change.
Check set operations without losing prior facts
For a multi-value field, list existing members, incoming members and the desired resulting set. Make the choice between replacement and addition explicit. A complete current classification may justify replacement; a partial contribution from another team may justify addition. Neither rule should be applied indiscriminately to every field with several values.
Include a second-run fixture to inspect what repeating the same planned update would do. Preserve the expected end state rather than assuming that another successful import means another improvement. Also include an unknown option and an unresolved record identifier so the reviewer can see how exceptions are separated from accepted changes. Keep the scope on mutation behavior; identity verification and permission to edit real records remain separate gates.
Accept the changed state rather than the row count
Compare the observed synthetic result with the expected-after column, not just the importer’s completed-row count. A row can process successfully while retaining a value the operator thought would be removed, or replacing a set the operator intended only to extend. Classify those as contract mismatches even if the interface reports no error.
Deliver the truth table, allowed operations and exception list to the data owner. State which source omissions are intentionally preserved and which corrections require another authorized process. Retain this fixture when a field type, import template or destination tool changes. The output is a precise change specification, not permission to upload customer data, clear properties or trigger downstream sales and marketing workflows.
Make the reasoning concrete.
A fictional account list contains two existing service-interest labels. A partner contributes one additional label for a synthetic record, while another column is empty because the partner has no current region information.
Treat the file as a complete record
Opening: Assume every input should replace the destination and blanks mean deletion.
Hypothesis: The spreadsheet looks like a simple new master list.
Risk: Partial knowledge can erase useful set membership or fail to perform the intended clearing.
Declare operations per field
Opening: Mark the label as an addition and the missing region as no new statement.
Hypothesis: The expected final record can be checked before import.
Risk: The template must encode supported operations rather than relying on visual emptiness.
The owner reviews a before-input-after row and rejects any operation the selected import path cannot express. The exercise uses only synthetic values and performs no live update.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Record
Which already identified synthetic record is being changed?
Before
What value or set exists before the input?
Intent
Is the operation preserve, replace, append or explicitly clear?
After
What exact final value is expected under the tool’s semantics?
Exception
Which row cannot safely express its intended change?
Watch for the wrong conclusion.
- Assuming a blank always deletes an existing value.
- Replacing a complete set with a partial contribution.
- Approving the operation solely from a successful row count.
Your next action
Write five before-input-after rows for a proposed import and resolve every ambiguous mutation before preparing the real file.
Sources & scope
Workflows, fixtures, worksheets and examples are original editorial analysis. Sources support the narrow attributed statements, not measured business results. Platform guidance is scoped to the documented implementation and date checked. Synthetic acceptance only; no external changes, messages or permissions are performed.
- Format import files →Primary platform documentation · Supports: Supports the narrow blank-cell and multi-checkbox mutation semantics. The truth table and fictional records are original; no import or deletion is performed.