# What you can do

> Declare the entities your business actually has, let the people who know them keep them current, and have every other part of the platform read the same list

Source: https://aipril.dev/docs/master-data/what-you-can-do

## 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](https://aipril.dev/docs/apps.md): 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](https://aipril.dev/docs/ai-organisation/people.md) 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](https://aipril.dev/docs/processes/automation.md) 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](https://aipril.dev/docs/processes.md).
- **Spreadsheets** can bind a column to it, with the same values and the same validity.
  See [Spreadsheets](https://aipril.dev/docs/spreadsheets.md).
- **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](https://aipril.dev/docs/analytics.md).
- **The ledger** refers to entries by code when it keys a balance by item or by counterparty.
  See [Ledger](https://aipril.dev/docs/ledger.md).
- **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](https://aipril.dev/docs/cms.md).

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](https://aipril.dev/docs/master-data/under-the-hood.md) - what makes a declared attribute fast, and the
rules that keep a shared catalogue trustworthy.