When a business needs a table of its own

Every business keeps records that no general product anticipated: a register of assets, a list of site inductions, a schedule of equipment tests.

Those usually start in a spreadsheet and eventually need a place beside the customers and jobs they concern.

The signal is a field called Notes

A Notes field holding structured information, in a format everybody has agreed informally, is a table waiting to happen.

Nobody can filter, total or report on it, and the format drifts between whoever typed last, which is the cost being paid quietly.

A spreadsheet beside the system is the same signal

A file somebody maintains separately, holding records that reference customers or jobs, splits the business's information in two.

Every report then needs somebody to join the halves by hand, and the two disagree within a month.

What a table of its own actually buys

• Fields with types, so a date behaves like a date and a number totals.
• Links to other records, so an asset belongs to a site and a site belongs to a customer.
• Filters and views, so somebody sees only what concerns them today.
• Reporting, because a real field supports a count, a total and a chart.
• Permissions, so sensitive records stay with the people who should hold them.

Each of those is impossible in free text and trivial once the information has somewhere proper to live.

Start from the questions, not the columns

A table designed by listing every field somebody can imagine produces forty columns, most of them empty.

Starting from the questions the business asks of those records shows which fields earn their place, and the list is always shorter.

Links are worth more than fields

An asset with a text field holding a customer's name cannot answer what that customer owns, and somebody will eventually spell it differently.

A link to the actual customer record answers that instantly, and it survives the customer changing their name.

Every record needs a name

A table whose records show as Untitled is unusable in a picker, a report or a list, whatever else it holds.

The naming field belongs on the create form and belongs required, which is a decision worth making before the first record exists.

Import the spreadsheet, once

The existing file holds real history, and rebuilding it by hand guarantees both errors and an unfinished migration.

Our guide to importing from a spreadsheet covers bringing it across cleanly and retiring the original.

Retire the old version deliberately

A spreadsheet left open beside the new table becomes the version somebody keeps updating, and then both are wrong.

Naming a date, telling everybody, and making the file read only is what completes the change rather than starting it.

Fewer tables, better linked

Three tables that should be one produce records scattered across screens and a report nobody can build.

The test is whether the records answer the same question. Where they do, one table with a type field usually serves better.

Some things genuinely belong in the product's own screens

Invoices, quotes and customers exist everywhere for a reason, and rebuilding them as a custom table loses the behaviour attached to them.

A table of your own is for what makes this business different, not for repeating what every business already has.

What to change first

• A Notes field holding structured information becomes a table
• A separate spreadsheet referencing customers or jobs moves into the system
• The design starts from the questions, not from a column list
• Relationships use links rather than typed names
• The naming field sits on the create form, required
• The old spreadsheet retires on a named date
• Records answering the same question live in one table