A Department Is a Name and a Description
Fourteen tables in this suite point at the department list — payroll, budgets, purchase orders, assets, tickets, projects and the workflow queue. The record they all point at holds a name and a description, and the settings menu calls it a cost centre.
The most heavily referenced record in an integrated operations suite is usually the least interesting one to build. Departments are a good example. Everybody needs them, nobody specifies them, and they get created early — in our case in the very first procurement migration, in 2024 — with the two fields that are obviously required and nothing else. Then, over two years, fourteen tables come to depend on them.
This is an article about what that record actually holds, what depends on it, and which of the things you would reasonably expect to be able to do with it you can do today. It is written about our own product because we can read the source, but the shape is general: check it in whatever you are evaluating.
What the record holds
A name, required, unique within your workspace, up to 255 characters. A description, optional, up to 255 characters. The workspace it belongs to, and who created, updated and deleted it. That is the whole record.
The settings entry for it reads Departments — Ownership & cost centers, and the settings search will find it if you type cost center, division, unit, branch or team structure. That is a fair description of what people use it for and a generous description of what it is.
What depends on it
Worth listing in full, because the breadth is the argument. Every one of these is a real foreign key to the same list.
| Module | What carries a department | What it decides |
|---|---|---|
| HR | The employment record | Headcount, leave liability and payroll cost by department |
| Access | The login | Which department a person may requisition for |
| Finance | The budget | Which budget line a purchase consumes |
| Procurement | The quotation request and the purchase order | Departmental commitment and spend |
| Procurement | The requisition — as a name, not a reference | The one place in the chain the department is text |
| Assets | The asset, its movements, its custodians, its pool balances | Who holds equipment, and what moved between departments |
| Service desk | The ticket and the ticket category | Which queue a request lands in, and the default routing |
| Projects | The project | Which department owns a body of work |
| Workflow | The task | Which department a queued task waits on |
Fourteen tables point at a two-field record. That is not unusual in an operations suite — it is what happens when a shared dimension is created before anybody knows how much will hang off it.
The three things people ask for, and where each stands
When somebody asks whether our department list is "a proper cost-centre structure", they almost always mean one of three specific things.
You want a code beside the name
Available today, as a custom field
Departments are one of the modules with custom fields enabled, so a cost-centre code, a general-ledger mapping reference or a funder code can be added to the record this afternoon, without a build, and it will appear on the department form. This is the answer to most of this article and it is the part people do not expect.
You want a hierarchy — divisions containing departments
A flat list, and a naming convention is the honest workaround
The record has no parent, so nesting is expressed in the name today: "Operations — Nairobi", "Operations — Mombasa". It sorts correctly, reports correctly, and does not roll up. If a rollup is a reporting requirement rather than a preference, it is a build and worth scoping as one.
You want a head of department who approves things
A different mechanism entirely, and the right one
Approval in this product is held by permissions and by workflow steps rather than by a field on the department. That is deliberate — a manager reference on a department record would be a second, quieter approval routing that disagrees with the first. Model the head of department in the workflow, where it is visible.
The custom field is the underrated answer
A cost-centre code you can add yourself, that appears on the department form, is worth more than a built-in field you cannot rename. It is also the only item in this article that requires nothing from us. If you are evaluating the suite against a chart of accounts that uses codes rather than names, start there.
Deleting a department checks four of the fourteen
This is the part worth acting on rather than merely knowing. Before a department is deleted, the product checks whether any login, quotation request, purchase order or requisition still points at it, and refuses if one does. Four checks, and they cover the procurement chain and access thoroughly.
The other ten references are not consulted, and each of them is declared to null itself when its department disappears. So a department with employees against it, a budget for the quarter, two hundred assets in custody and an open ticket queue — but no logins and no procurement history — deletes cleanly, and those references become empty.
Which references stop a delete, and which are nulled
In practice a long-established department has procurement history or a login against it and cannot be deleted at all, which is why this has not bitten anybody yet. The exposure is a department that was set up for people and equipment and never used to buy anything — a ward, a site, a school department, a programme team.
Before you delete a department, five minutes
- Filter employees by that department and reassign or note them.
- Check whether a budget exists for it in the current or a past period.
- Filter assets and custodians by it — this is usually the largest number and the easiest to forget.
- Check the ticket categories for one whose default routing points at it.
- Then delete it, and expect a refusal if it has any procurement history at all.
- Or simplest: rename it rather than deleting it. A department that is no longer used costs nothing to leave in place, and renaming keeps every reference intact.
There is no one-department screen
The department list shows an identifier, a name, a description and the edit and delete actions. Above it are two figures: how many departments you have, and how many of them have been given a description. There is no page for a single department, and therefore no place that answers the question everybody eventually asks — what does this department cost us, hold, request and owe?
That question is answerable today, in pieces, from the modules: headcount and payroll cost from HR, commitment and spend from the finance reports, custody from the asset register, workload from the service desk. Every one of those reports can be filtered or grouped by department. What is absent is the page that puts them side by side.
What AWRA OpsHub does today
- One department list, unique names within a workspace, referenced by fourteen tables across HR, access, finance, procurement, assets, the service desk, projects and the workflow engine.
- Custom fields on departments, so a cost-centre code, a general-ledger reference or a funder code can be added to the record without a build.
- Two seeded defaults locked against edit and deletion, so the department the system itself relies on cannot be renamed out from under it.
- Deletion refused where a login, requisition, quotation request or purchase order still references the department.
- Separate permissions to view and to manage the list, and a settings entry findable under cost center, division, unit, branch and team structure.
- Grouping or filtering by department in the HR analytics, budget, purchase-order, asset-register and service-desk reports.
More we can add to your workspace
- A delete check covering all fourteen references, so a department holding employees, a budget, assets or a ticket queue is refused as firmly as one holding a purchase order.
- A single-department page — headcount, payroll cost, budget, committed and actual spend, assets in custody and open tickets on one screen.
- A parent department, so divisions can contain departments and a report can roll one up into the other.
- A cost-centre code as a first-class field, indexed and selectable, for organisations whose chart of accounts is coded rather than named.
- An active-or-retired flag on a department, so an unused one can be taken out of the pickers without being deleted or renamed.
- A department reference on the requisition, replacing the free-text name that is the fifteenth and only textual carrier of the dimension.
Where we point you to a specialist
- A head-of-department field on this record is one we would argue against rather than schedule. Approval routing belongs in the workflow engine where it is visible and auditable, and a manager reference on a department would become a second routing that quietly disagrees with the first.
- A department is not a general-ledger account and we do not intend it to become one. Where an organisation needs departmental accounts in the ledger itself, that is a chart-of-accounts design question and we would rather map to your accountant's structure than invent one.
- Where a statutory or funder-mandated cost-centre structure has to be signed off, we point you at your auditor for the structure and build to it. We do not certify that a department list satisfies a funder's requirements.
The delete check is small, contained and the one we would do first. The single-department page is the one customers actually ask for. Tell us which matters to you and we will come back with a written scope for it.
What we would add, and in what order
Two of these are small. One is a proper piece of work. They are listed in the order that gives you value soonest.
Complete the delete check
Extend the four existing checks to the other ten references. Same pattern, same message, and it turns a quiet data loss into a refusal.
A retired flag and a code
A department you can take out of the pickers without deleting, and a code field that is indexed rather than a custom field. Both small, both requested more than the hierarchy.
The single-department page
People, cost, budget, committed and actual spend, assets, open tickets. The reports already produce every figure; this is the page that stops six of them being opened one at a time.
We publish scope, not dates.
Scope the department recordFive questions about the shared dimension in any suite
What fields does a department record hold?
A good answer sounds like
A short, specific list.
What ours actually is
A name and a description, plus custom fields you define. Ask this of any vendor; the shared dimensions are where the specification was thinnest in every product either of us has seen.
Which modules reference it?
A good answer sounds like
An enumeration, not "everywhere".
What ours actually is
Fourteen tables, and one of them holds a name rather than a reference.
What happens when I delete one?
A good answer sounds like
A refusal listing what still points at it.
What ours actually is
A refusal for four kinds of reference, and a quiet emptying for the other ten. Ask for the demonstration rather than the answer.
Can I add my own code to it?
A good answer sounds like
Yes, and here is where.
What ours actually is
Yes, as a custom field, today. This is a better answer than a built-in field, and it is rarely mentioned.
Show me one department and everything about it.
A good answer sounds like
A single page.
What ours actually is
Six reports, each filtered. The page is on the list above.
Our take
A two-field record carrying fourteen dependencies is honest engineering history rather than a design, and the sensible response is not to be embarrassed about it. Use the custom fields for codes — that closes the requirement most organisations actually have. Express hierarchy in the name until a rollup is a genuine reporting need. Model the head of department in the workflow rather than asking for a field. And do not delete a department: rename it, because the delete check covers the procurement chain and not the ten other things pointing at it. The one item on this page we think should simply be fixed rather than scoped is that check.
Audit your department list this afternoon
Open the list, and for each department ask whether anybody could say what it costs, holds and owes without opening six reports. Then add a code as a custom field while you are there. If you would like the single-department page, it is scopeable — tell us what six figures you would want on it.
Scope the department pageFrequently asked questions
Can I add a cost-centre code to a department?
Yes, today, as a custom field — departments are one of the modules with custom fields enabled, so the code appears on the department form and on the record without any build. It will not be an indexed, first-class column, so a report that groups on it behaves like a report grouping on any custom field. For most organisations that is sufficient and it is the fastest route to a coded structure.
Can departments be nested under divisions?
The list is flat — the record has no parent — so nesting is expressed in the name, which is why you see conventions like "Operations — Nairobi". That sorts and reports correctly and does not roll up. If a division-level rollup is a reporting requirement, it is a build and worth scoping properly rather than approximating.
What happens if I delete a department by mistake?
It is refused outright if any login, requisition, quotation request or purchase order still points at it, which covers most established departments. Where it does go through, the other references — employment records, budgets, assets, custodians, tickets, projects and workflow tasks — are set to empty rather than deleted, so the records survive and the department on them does not. Renaming rather than deleting avoids the question entirely.
Is there a head of department field?
No, and we would argue against adding one. Approval routing lives in the workflow engine and in permissions, where it is visible and auditable; a manager reference on the department record would become a second routing that can silently disagree with the first. Model the head of department as a workflow step or a permission holder.
Why does the requisition hold a department name rather than a reference?
History — the requisition was created in the first procurement migration in 2024, and the reference was added to quotation requests and purchase orders in 2026. The consequence is a name-matching join in the middle of the chain, and it is worth understanding before you agree your department names: see A Department That Is Only a Word.
Does an inventory, procurement, financial controls and HR suite normally share one department list?
The good ones do, and it is the right question to lead with when comparing them. A suite where each module keeps its own department list cannot produce a departmental figure that crosses modules at all — you get four lists that drift and a spreadsheet to reconcile them. One list, referenced everywhere, is the foundation; how rich the record is comes second, and can be closed with custom fields far more easily than a missing shared dimension can be retrofitted.
Where do I find the department list in the product?
Under settings, described as "Ownership & cost centers", and the settings search will find it if you type cost center, division, unit, branch or team structure. Viewing it needs the settings view permission and editing it needs the settings management permission.
