Clean a CSV without losing what it means.

Define the columns before transforming values

Start with a small sample and explain the business meaning of each column. An order ID is an identifier even if it contains only digits. A blank quantity may mean unknown rather than zero. A date without a specified convention can be ambiguous. The cleaning rules should follow those meanings instead of guessing from cell appearance.

Keep the original file in the Project and ask for a separate result. Name the intended consumer: a spreadsheet, a report, or an App. That choice affects what to verify after export. A visually correct preview does not establish how another tool will interpret leading zeros, date strings, or decimal separators.

Inspect the data before choosing rules

Ask for a profile containing row count, column names, missing-value counts, and examples of unexpected values. Include the candidate duplicate key rather than requesting “remove duplicates” without a definition. Two rows with the same customer name may represent different orders; two identical-looking rows may need a source-system check.

Classify proposed changes as formatting, interpretation, or removal. Trimming accidental surrounding whitespace differs from deciding that “03/04” means March 4. The former may be appropriate under an agreed rule; the latter needs a date convention. Keep unresolved rows available for review instead of silently coercing them into valid-looking values.

Review fictional order-cleaning decisions

This fictional sample represents an order export, with order_id defined as text and quantity defined as a whole-number count. The source has no confirmed date convention. The table shows decisions to make before running transformations; it does not describe automatic CSV rules built into Workspace.

Notice that an empty value and a zero lead to different outcomes. Replacing both with zero would make a sum easy to calculate but change the meaning of the data. Similarly, preserving an ambiguous date as unresolved is more useful than producing an apparently complete timeline from a guess.

Apply the agreed rules and keep an audit trail

After reviewing the proposal, request the cleaned copy and a transformation log in formats suitable for your task. These are requested deliverables, not a promise of a fixed built-in cleaning pipeline. Name each rule, the affected column, and how many records it changed. Keep the unresolved rows identifiable by a stable source reference.

If the Agent uses scripts, ask for a concise explanation of the transformations and their checks. The active environment must support the required operations; a normal browser Session does not gain access to arbitrary local files. Upload the source or use the explicitly selected environment appropriate to the work.

Reconcile counts and totals before trusting the copy

The reconciliation should account for every input row: retained, combined under an approved rule, removed for a stated reason, or held for review. Do not compare only the final row count. A result can preserve that count while moving values into the wrong column or converting identifiers incorrectly.

Check relevant totals for fields with known numeric meaning. Compare totals before and after permitted transformations and explain any difference. For a derived metric, show its denominator and treatment of unknowns. Open the saved file and inspect examples from every rule, including at least one unresolved record and one record expected to remain unchanged.

Test the file in its destination workflow

Load the result where you plan to use it and inspect the same representative rows. A spreadsheet may interpret values differently from an App. Confirm identifiers, accented text, quoted commas, date fields, and empty values. Do not assume that a successful save proves compatibility with every downstream importer.

If counts or meanings change after import, isolate the problem at that boundary before cleaning the source again. Keep the checked result and its rules in the Project. When another export arrives, reuse the method but profile the new input first; a changed column name or date convention can invalidate a previously successful transformation.

Try it with a small example.

Before you use the result.

• The original is preserved and transformation rules are explicit.
• Unknowns, zeros, and identifiers retain their meanings.
• Every input row is accounted for.
• Important totals reconcile with explained differences.
• The destination tool interprets representative values correctly.