An internal tool usually starts with a clear purpose and ends up with a pile of tables nobody feels responsible for. Customers appear twice, a status column means different things to two departments, and an import from last spring quietly overwrote prices. The code is rarely the problem. The problem is that nobody was asked to look after the data.
The fix is small: one named person for each table, a few written rules and a yearly check. This article describes how to set that up in an afternoon.
Start with an inventory
Ask the developer, or open the database yourself, and list the tables the tool uses. For a small tool this is often ten to thirty. For each one write down:
- the table name and one sentence in plain words ("Customers we have invoiced at least once"),
- where the data comes from (typed in by staff, imported, copied from another system),
- who reads it and which reports or screens depend on it,
- how many rows it has today, so a later check can spot odd jumps.
Do not aim for perfection. A rough list on one page is enough. Tables that nobody can explain are the first finding: they are either leftovers or hidden dependencies.
Name one owner per table
Pick a person, not a team or a role such as "the office". "Finance" cannot answer a question on Friday afternoon; Jana from finance can. The owner should be someone who uses the data for their own work and understands what a wrong value costs.
The owner is responsible for the meaning and quality of the data:
- what each column means and which values are allowed,
- who may add, edit or remove rows,
- what to do when two sources disagree,
- answering questions from the developers about the table.
The developer or IT provider is responsible for the system: backups, access, performance and applying changes. They should not decide whether two customer records are the same company. That is a business decision.
One owner can have several tables, but a table never has two owners. If two departments both claim it, ask who is hurt most by bad data and start there.
Write the change rules
Short rules prevent most data accidents. Put them next to the inventory, one line per table where needed:
- Who may edit. A named group of users, not everyone with a login.
- Bulk changes need approval. Imports, mass updates and deletes of more than a handful of rows go to the owner first, with a before/after sample.
- Never delete, mark instead. For records tied to money or contracts, use an "inactive" flag so history stays readable.
- Take a copy first. Before any bulk change the developer exports the table and keeps the file until the owner confirms the result.
- Record the change. A line in a shared log: date, who, what, why.
For how long to keep different kinds of records, see a data retention schedule for business records. For the wider picture across several systems, a one-page register of who owns the data in each business system works well alongside this per-table view.
A yearly data quality check
Once a year, each owner spends about an hour on their tables. The check is deliberately simple:
- Row counts. Compare with last year and with the inventory. Large unexplained changes get a question to the developer.
- Sample. Open twenty random rows and compare them with reality: is the address right, is the contract still active, does the person still work here?
- Empty and odd values. Count blank required fields, impossible dates and values that appear only once.
- Duplicates. Look for the same customer, supplier or product entered twice. If you find many, a two-week cleanup with one owner gives a method.
- Access. Check the list of people who can edit. Remove those who changed role or left.
- Write it down. Three lines per table: what was checked, what was wrong, what was fixed or planned.
Choose a fixed month, for example just after the year-end close, so the check does not depend on anyone remembering.
Handing over when someone leaves
The moment the owner leaves is the moment tables lose their owner. Add one step to the leaving checklist: the owner lists their tables, names a successor, and spends thirty minutes walking the successor through the meaning of the main columns and any known problems. The successor confirms by email. The inventory is updated the same day.
The same applies when a tool is retired: the owner decides what is exported and what is deleted, as described in a sunset plan with data export, notice period and last-day checks.
Common mistakes
- Owner by committee. "Everyone is responsible" means nobody answers.
- Owner equals developer. Developers can protect the data, but they cannot know what a value should be.
- Rules nobody can find. Keep the inventory and rules where staff already look, such as the intranet or the tool's help page.
- A check with no follow-up. Findings without a date and a name are forgotten by spring.
- Copies in spreadsheets. Exports used for daily work drift away from the tool. Agree which one is the source of truth.
Summary
Good data in an internal tool is mostly a matter of naming people. List the tables, give each one a single owner, write five short change rules, check a sample once a year and hand tables over in writing when people move on. It costs a few hours per year and spares you the afternoon when a report is wrong and nobody knows why.
Sources
- Common practice for building and supporting internal tools, offered as a practical guide. No client results or market figures are claimed in this article. Adapt the owners, the rules and the check interval to your own tool, and take local rules on personal data and record keeping into account where they apply.
