What belongs here
Anything the rest of the platform refers to by name and does not own:
- Products and services - with whatever describes them in your business: category, unit, packaging, shelf life, supplier code, hazard class.
- Warehouses, sites, points of sale - the places things are, and are moved between.
- Counterparties - customers, suppliers, contractors, with the attributes your processes route on.
- Price lists and rates - what something costs, per list, per period.
- The classifiers nobody thinks of as data - request types, reasons for rejection, statuses of things that are not processes, categories used on three different forms.
That last group is the one that usually has no home at all, so it ends up duplicated as three slightly different dropdown lists that disagree by the second quarter.
Any catalogue, any shape
There is no fixed list of catalogue types to choose from. Whatever your business actually has becomes an entity: equipment classes, contract types, service levels, hazard categories, routes, tariff zones - with the attributes that describe them in your case and no others.
The platform's own schema imposes nothing on that. Adding an attribute is a declaration, not a migration somebody has to write, deploy and schedule. So the answer to "can we have a catalogue of X" is always yes, and the only real question is which of its attributes need to be searchable and joinable - because those are the ones that get indexed.
Declared by the application, maintained by people
An entity arrives as part of an application: the app declares what a product is in your case, and which of its attributes need to be filtered, sorted or joined on.
From then on it is ordinary data that people maintain. The category manager edits the catalogue; the purchasing team keeps the counterparties current; nobody files a ticket to add an attribute value. And when the application is updated:
- new entries the update brings are added;
- entries that already exist are left alone, including every correction your people made;
- nothing is deleted behind your back.
That combination is what makes a shipped catalogue usable in a real installation instead of something to be overwritten twice a year.
Choosing one narrows the next
Real forms have dependent choices. Pick the department and the list of positions should show that department's positions, not all four hundred of them. Pick the category and the products should narrow to it.
A picker can therefore depend on another field beside it, and the dependency is declared by the application instead of written into each screen, so the same entity behaves the same way everywhere it appears: in a process form, in a spreadsheet column, on a portal page. References into the org structure do this without being asked, narrowing by the org field already filled in on the same record.
The effect is the ordinary one people expect from good forms and rarely get: fewer wrong choices, because the wrong ones were never offered.
Filled from an outside system
A catalogue does not have to be maintained by hand, and often should not be. The product list may belong to an ERP, the counterparties to an accounting system, the tariff zones to somebody's service.
An automation can keep the catalogue in step: call the external service, and write what comes back - create or update an entry, or deactivate one that has disappeared upstream. On a schedule, or on an event from the system that owns the data.
Two properties make that safe to leave running:
- Updating is by code, so running the same sync twice changes nothing the second time. A nightly job that overlaps itself, or a retry after a network failure, does not produce duplicates.
- Disappearing upstream deactivates rather than deletes, so records that already refer to an entry keep working while it stops being offered for new ones.
And where a list should not be stored here at all - because it is enormous, or because it changes by the minute - a picker can resolve its options directly from a remote service instead.
One list, every surface
The point of master data is that there is one of it. Once an entity exists:
- Forms and processes can bind a field to it, so a request names a real supplier from the real list and not free text somebody typed. See Processes.
- Spreadsheets can bind a column to it, with the same values and the same validity. See Spreadsheets.
- Reports join to it as a dimension - sales by product category, movements by warehouse - which is the normal way an analytical model is built. See Analytics.
- The ledger refers to entries by code when it keys a balance by item or by counterparty. See Ledger.
- Pages get management screens and can drive their own navigation from an entity, so a menu of categories is the category list, not a copy of it. See Portals and pages.
Change a name in one place and every screen that shows it changes. Deactivate an entry and it stops being offered - without breaking the records that already refer to it.
Next
Under the hood - what makes a declared attribute fast, and the rules that keep a shared catalogue trustworthy.