A practical guide to preparing your tables

Write down the intended output before changing the data. A combined supplier catalogue, a difference report, and a contact-import file need different decisions. Keep an untouched copy of each source and note its export date. If a system offers both a full export and a filtered export, confirm which one you received. The workbench can describe supplied records, but it cannot detect records that were never included in the source. A small representative sample is a useful way to learn the controls before processing the complete dataset.

Choose a stable identifier where the task involves matching. Product names and customer names often repeat or change spelling. A product code, customer number, or confirmed combination of fields may be more appropriate. Check blank and duplicate keys before relying on a comparison. If a key is not unique, decide whether the extra matches represent legitimate detail rows or an unresolved ambiguity. Do not remove them merely to make a tool run successfully.

A CSV file is a text representation of records and fields. Its extension does not tell you every parsing choice. Check the delimiter, header row, quoting, and any introductory records that need to be skipped. A comma inside a quoted description belongs to that field; a newline inside a quoted field does not necessarily begin a new record. Review several parsed rows and verify that values sit under the intended headers before confirming the import.

If text looks garbled, investigate the source encoding before changing cell values. Use the encoding tool to inspect the original bytes and choose a supported interpretation. Saving already corrupted text with a new encoding does not recover lost characters. If columns are uneven or quotes are incomplete, use structure diagnosis and inspect any proposed repair. Keep excluded or unresolved records visible in your review. A partial output should not be mistaken for a complete restoration.

Codes such as 00123 are identifiers even though they contain digits. Keep them as text when their spelling matters. Long identifiers can also be damaged if another application turns them into limited-precision numbers. The workbench preserves text inputs, but a receiving spreadsheet can infer types when you open the exported file. Use that application’s import controls to keep identifier columns as text, then inspect a few known values after importing.

Date and number conversion should follow the source data’s convention. Confirm whether 03/04/2026 means March 4 or April 3 rather than using interface language as a guess. Check whether 1,234 means a grouped integer or a decimal value. Currency symbols, percentage signs, blank markers, and time-zone offsets can change interpretation. Review failed or ambiguous values separately and keep original fields when you need an explanation of how a new value was derived.

Suppose one file has SKU, Name, Price and another has Price, Product ID, Name. Pasting raw text underneath the first header would put values in the wrong columns. In the merge tool, confirm each file’s headers and map Product ID to SKU only if both represent the same identifier. The same-column strategy can then align different column orders. The all-columns strategy preserves fields that appear in only some sources, leaving empty positions where a source has no corresponding field.

The shared-columns strategy intentionally discards fields absent from any selected input. Review that loss before confirming. Appending does not deduplicate, so two files containing the same SKU still contribute two records. Check that the output count equals the sum of the included source records. Preserve source information if later steps need to explain where competing values came from. File order also matters when a subsequent rule keeps the first or last occurrence.

A join adds fields by matching selected keys. Before running it, consider whether each source key should have one match, several matches, or no match. Several records on both sides can multiply output rows. Review unmatched and duplicate-key reports, and confirm that the larger result represents a real relationship. Cleaning spaces or changing case may help some keys match, but only apply those rules when they preserve the meaning of the identifier.

A comparison is different: it asks what changed between two datasets. Key-based matching can ignore row order, while position-based comparison treats location as meaningful. Choose the fields whose changes matter. A description edit should not be reported as a price change if descriptions are outside your question. Keep old and new values with the report so that another reviewer can understand the difference without reconstructing the entire operation.

For a calculation, choose a few rows whose expected answer you can compute independently. Include a normal value, a blank, a negative value where relevant, and an invalid value. Check rounding and missing-value rules. Running totals depend on order and grouping; equal timestamps need an explicit decision about sequence. A rolling average over records does not become a calendar average simply because the ordering field contains dates.

Reshaping also needs a count check. Expanding three selected items into three rows repeats the surrounding fields, including any amount. Summing that amount afterward can triple its contribution. Unpivoting creates attribute-value records from selected columns, while pivoting aggregates records into cells. Determine which columns identify the entity and which contain measurements. Keep an original identifier in the output whenever it will help you trace an unexpected row back to its source.

Grid search and pagination help you inspect a result; they do not necessarily change the dataset you download. Choose the export scope explicitly: the complete result, changed records, unmatched records, or another report offered by that tool. Confirm the format, header handling, and UTF-8 BOM option. Read any notice about formula-like values and protected output. A protective prefix can affect the text that a downstream application sees, so it should be an informed choice.

Generated table exports are reread for structural and value checks before download where the tool provides that verification. The check confirms the generated representation against the intended output; it is not an external business audit. Reopen the downloaded file using suitable import settings and inspect identifiers, row counts, and a few boundary records. For an archive, inspect the manifest and the contents of more than one part, especially around a split boundary.

Export useful results before refreshing, closing, or clearing the page. The general table workbench keeps an in-memory workflow across compatible in-site navigation, but specialised tools can use separate workspaces. A saved rule file records settings, not a full backup of the table. Keep the result and relevant reports alongside the original files if you need to repeat the task later or explain the decisions to a colleague.

Calendar, contact, and store-import files have destination-specific requirements. Generating an ICS, VCF, or product CSV does not connect to the destination account. Test a small, clearly identifiable batch first and check how the receiving application handles time zones, duplicates, fields, and updates. If it reports an error, keep the exact message and reproduce it with fictional data where possible. Correct the cause before importing the complete dataset.