Already live in the product
Running in production today: master records for locations, departments, and business units.
/mastersBuilt around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
What teams can do here
How it works
A worked example
A typical retail chain opening its 12th store sets masters up first: each store as a location with code and city, stockroom and shop floor as sub-locations, and departments — Operations, Visual Merchandising, IT — with their heads on record. When the new store’s POS terminals are registered as assets, location and department are picked from those masters, so “Store 12 – Stockroom – IT” means the same thing on the asset register, on the ticket an engineer raises about a faulty terminal, and in the quarter’s asset report. When Store 3 closes, its location is switched inactive — history intact, nothing new recorded against it.
Why free-text reference data quietly breaks IT reporting
Most inventories start in a spreadsheet, and the damage starts there too: one technician types “HQ”, another “Head Office”, a third “hq-3rd-floor”. Each variant becomes its own bucket, so a simple question — how many laptops sit in the head office? — needs manual cleanup before it can be answered. The same drift hits departments (“IT”, “I.T.”, “Information Technology”) and cost centres, and it compounds with every month of data entry.
Masters remove the typing entirely. A location, department or business unit is created once as a record with its own code, and every other screen selects it rather than re-describing it. When the register says an asset is in “HQ – 3rd Floor – Finance”, that is one specific chain of records — not a string that happens to look similar to another one.
The payoff shows up wherever data is aggregated: asset counts by site come out right the first time, filters return everything they should, and a report grouped by department has one row per department instead of five near-duplicates.
- Location hierarchy: location → sub-location → floor, each with its own code
- Org structure: departments, sub-departments and business units / cost centres
- Classification: component / CI types with a category such as hardware, software or network
- Lifecycle: active/inactive flags instead of deletes, so history stays readable
One set of masters, referenced across the workspace
Master records are not a standalone catalogue — they feed the location, department and business-unit fields used across the workspace. Register an asset and its location is picked from your sites; raise a ticket and the department behind it is the same record the org structure uses; run a report and its groupings follow that same structure. Component / CI types work the same way, keeping hardware, software and network classifications uniform wherever they appear.
Because every master is organisation-scoped and unique within your tenant, this consistency never leaks between companies on the platform: your structure is yours alone. And because records carry an active/inactive flag instead of being deleted, closing an office or dissolving a team stops new use without corrupting the history that references it.
A practical setup order that pays off later
Treat the masters module as step zero of a rollout. Define locations first — sites, then sub-locations and floors — because almost everything physical hangs off them. Then add departments, sub-departments and business units so ownership and cost attribution are selectable from day one. Finish with component / CI types so classification is settled before the first asset is registered.
Doing this before loading assets or opening the helpdesk takes perhaps an hour for a mid-size organisation, and it is far cheaper than retrofitting: reference data created after the fact means re-touching every record that guessed at a location or department in the meantime. Teams that start with clean masters get consistent filters, believable dashboards and audit-ready exports from the first week.
A reorganisation is the same discipline in reverse: add the new departments, move active use across, and deactivate the old records once nothing new points at them. Historical reports keep their original groupings, current ones pick up the new structure — no bulk find-and-replace, no orphaned strings.
Frequently asked questions
What reference data can I keep as masters?
Are masters shared across other companies on the platform?
Can I nest locations and departments?
What happens to history if a location or department closes?
Why set up masters before assets and tickets?
How do masters stop two teams describing the same thing differently?
See also: Guide: what good asset management looks like · Guide: the IT asset lifecycle end to end · Asset management · Helpdesk ticketing · Reports & automation
Explore connected offerings
Get the boring data right once
Locations, departments, business units and CI types defined as single reusable records — so every screen that references them says exactly the same thing.