Versioned reference tables

Define the table once

Each table has named columns with a type: text, whole numbers, true or false, and cells that may be empty where you allow it. Every row has its own identifier, and one or more key columns must be filled in and unique. Identifiers and decimal values are kept as text, so nothing is rounded or reformatted.

Columns, types and keys are agreed with your team during onboarding, then fixed for that table.

Edit in the grid or paste rows

Edit cells, add or remove rows, or paste CSV or spreadsheet cells with their header row. Pasted rows can be merged into the table by row identifier, or propose a complete replacement. Headers and types are checked, and codes are never trimmed or columns dropped to make a paste fit.

Review the whole change

Review checks the whole proposed table and counts what is added, changed, removed and unchanged, with the values before and after. Removals are confirmed explicitly, and a note records why the change was made. The save is bound to exactly what was reviewed.

A proposal with a problem, such as a repeated row identifier or an empty key, is refused as a whole. The saved version stays as it was until the draft is corrected.

What if two people edit the same table?

Each draft records the version it started from. If someone else saves a newer version first, review refuses the older draft, so their change is never overwritten. Keep the draft, compare it with the current table, then reload and review a fresh proposal.

Keep every version

Each save creates a version that never changes, with its rows, author and note. Inspect earlier values when investigating why a label reference or a generated job differed. Look up an exact code to see every table that holds it and the version it came from.

Saving is not activating

A saved version is a set of values, not an active configuration. Saving a table does not generate a file or change any product. The receiving product takes data from a version you choose and reviews it first: see reviewed file transfers.

Who can do what

People sign in through SmartFACT Accounts. Owners set up tables; operators edit them; viewers inspect and export. Setting up a table needs a recent two-factor check. An owner can also download a complete export of the organisation’s data.

Read next

• Reviewed file transfersA reviewed file transfer hands data to another system as a file the receiver checks first. See how SmartFACT Data prepares LabelRules and KitProof files from saved versions.
• What is a config sheet?A config sheet is a table of reference values, such as product option codes or customer codes, that other systems look up. How they go wrong, and how to keep them right.
• Use casesWhere manufacturers use config sheets: customer codes on labels, supplier option codes, EDI, kit inputs, shop SKUs and configuration behind your own tool.