Keep identifiers intact from export to import
In this article
An identifier can look like a number without behaving like a quantity. Product code 0017 and product code 17 may refer to different things, even though a numeric conversion makes them equal. Protecting identifiers means preserving their exact characters throughout the workflow, including the application that opens the exported file. This article proposes a practical review sequence for codes, postal fields, and external keys. Its examples are invented, and it does not assume that every source system uses the same identifier rules.
Decide which columns are identifiers
Begin with the field's purpose. Ask whether addition, averaging, or numeric ordering would have a meaningful interpretation. A quantity ordered and an order reference may both contain digits, but only one normally belongs in arithmetic. Put fields used for matching into a separate list before applying broad cleaning, conversion, or validation rules to the table.
Record permitted length, case, punctuation, leading spaces, and leading zeros where the source specification defines them. Do not invent a fixed length from a few visible examples. A collection containing four-character codes today may also permit longer codes. The source owner or destination contract should determine validity; the sample merely helps you ask the right questions.
Understand where conversion happens
A CSV file stores delimited text, not spreadsheet cell formatting. Microsoft documents that Excel can remove leading zeros and convert long numeric text, and describes importing selected columns as text to preserve them. A spreadsheet preview that displays 17 therefore does not establish whether the original file contained 17 or 0017. Inspect the source text before deciding what to repair.
Separate three checkpoints: the file produced by the source, the representation inside your editing application, and the saved output. Compare a known identifier at each point. If it changes only when the file is opened in another application, changing the exporter may solve the wrong problem. The import settings of the receiving application need attention instead.
Inspect without guessing missing characters
In Rowlane, the table parser retains values as text. Use Column picker to reduce the review to the identifier and a few context fields, then examine the preview. Value frequency can help locate exact repeats, while Column statistics can describe text lengths. Neither tool can recover characters already removed by a previous application or infer an authoritative replacement.
For an invented example, compare codes 0017, 17, and A017. Treat them as three distinct strings unless a documented rule says otherwise. Adding zeros to every short value would turn an observation about length into a transformation of identity. If the source has already lost zeros, obtain a fresh export or an approved mapping rather than padding by appearance.
Keep matching rules deliberate
Before comparing snapshots or joining tables, confirm that both sides use the same identifier representation. Exact comparison will distinguish ABC from abc and a value with trailing spaces from one without them. That can reveal an export difference. It can also prevent a match that a business process expects, so investigate the reason before normalizing either side.
When trimming or case conversion is justified, keep the original identifier in an untouched source copy and document the normalized matching field separately. Check whether normalization causes previously different strings to collide. A match rule that merges AB and ab is safe only when the identifier system permits that equivalence. A more attractive preview does not answer that question.
Choose an output for its consumer
Rowlane's JSON conversion preserves table values as strings, so an identifier such as 0017 appears within quotation marks. That is useful when a receiving process expects text fields, but it does not automatically satisfy the process's schema. Confirm required property names, accepted characters, missing-value rules, and any maximum length before choosing the export format.
For CSV and TSV, configure the destination to import the identifier column as text where possible. Quoting a CSV field primarily protects delimiter structure; it is not a portable declaration that every spreadsheet must interpret the field as text. RFC 4180 describes quoting conventions, while applications still make their own interpretation decisions.
Check the saved artifact
Review a small set of deliberately varied identifiers after downloading: leading zeros, a long digit sequence, letters, punctuation, and any permitted whitespace. Compare exact strings against the original file. Include an example near the documented length limit if one exists. Use synthetic values for testing rather than copying real account or personal identifiers into a support request.
Test the same saved artifact through the receiving system's actual import route. Opening it by double-click and importing it with selected column types can produce different results. Record which route was used. If the receiving process changes identifiers, stop and resolve that behavior before treating matching failures as missing records or creating replacement entities.
Make identifier rules part of the handoff
Supply a short note stating which fields are identifiers, their authoritative source, and which transformations are prohibited. Include a synthetic example showing why 0017 must remain distinct from 17 when that distinction matters. The note should travel with the output, because a later reviewer may otherwise repeat the conversion you carefully avoided.
Preserving identifiers is a chain of explicit choices. A browser tool can keep source text intact during its own operations, but the source export, spreadsheet settings, saved format, and destination import all need review. Check those boundaries with known strings, and keep unresolved differences visible instead of inventing a repair that merely makes the values look consistent.