One Person, Two Departments
HR records which department an employee belongs to. Procurement asks which department a login belongs to. These are two columns on two tables, and the moment HR issues that employee a login, the department does not come with it.
The finding, immediately
A person in this product has a department twice: once on their employment record, where HR puts it, and once on their login, where an administrator puts it. Payroll, leave and headcount read the first. Requisitions and quotation requests read the second, and only the second. When HR creates a login for an existing employee, the login is created with seven fields and a workspace id — and a department is not one of them. The employee is in Finance and their login is in nothing, so their first requisition is refused with a message about their profile.
Almost every argument about integrated operations software is about modules: whether inventory, procurement, finance and HR are one system or four. That is the wrong unit. What decides whether a suite behaves as one system is whether a fact entered in one module is the same fact when another module reads it — and the cheapest way to test that is to pick something small, obvious and shared, and follow it across a seam.
A department is a good choice. Everybody has them, nobody thinks they are complicated, and four modules need to know about them. This is what happened when we followed one across the HR-to-procurement seam in our own product.
Two columns, one organisational unit
There is one department list. There are two places a person can be attached to it.
The same idea, held twice
The column Who fills it in
The employment record HR
Set when the employee is created or imported, alongside position, manager, employment type and hire date. This is the department an HR manager means when they say somebody is in Finance.
The login User administration
Set on the user record, in a different module, by whoever administers access. It is optional, and a login created any other way starts empty.
Both point at the same department list, so they agree whenever somebody remembers to set both. Nothing checks that they do, and nothing reports when they disagree.
Which department each answer is computed from
This is the part worth reading slowly, because the split runs exactly down the middle of the suite.
| The question | Reads | Consequence when the two disagree |
|---|---|---|
| What does this department cost us in salaries? | The employment record | Correct, because payroll and headcount never look at logins |
| How many people are in this department? | The employment record | Correct |
| What is this department's leave liability? | The employment record | Correct |
| Which department is this requisition for? | The login | Stamped from the login, or refused when the login has none |
| Which department is this quotation request for? | The login | Same |
| Which department's budget does the order consume? | The order, inherited from the request | Inherits whichever department the login carried |
Cost is attributed from one column and authority from the other. They are usually the same value, and nothing in the product depends on that being true.
The seam is a button in HR
The join between the two records is real and deliberate. An employment record holds an optional reference to a login, one login to one employee, and HR has a screen that provisions a login for an employee who has not got one — the right design, because it means an employee can exist without ever being given access, which is the normal case for most of a workforce.
That screen builds the new login from the employment record: the name, the email address, a random password, a forced password change on first sign-in, a role chosen by the administrator, and a welcome email. Then it writes the new login back onto the employment record so the two are linked. Seven fields and a workspace, and every one of them is right.
The department is not copied. The link between the two records is created in the same transaction, and the department sits on one side of it.
What crosses the seam, and what stops at it
On the employment record
Entered by HR
- Full name
- Email address
- Employee number, position, manager
- Employment type, status, hire date
- Department
On the login it creates
What procurement will read
- Name — copied
- Email — copied, and checked for global uniqueness
- A random password and a forced reset
- A role, chosen by the administrator
- Department — empty
The employee is linked to the login in the same database transaction that creates it, so there is no timing problem and no failure to report. The department is simply not part of the payload.
What the person actually experiences
-
HR adds the employee and sets the department
Finance. Recorded correctly, and from this moment their salary, leave balance and headcount all attribute to Finance.
-
HR provisions their login
One screen, one role, a welcome email. Everything about it succeeds, and there is nothing on it to warn anybody.
-
They sign in, set a password, and raise a requisition
The department field is not offered to them, because for a non-administrator it is not a choice — it is taken from their login, which is the correct design.
-
The requisition is refused
"Your profile is missing a department. Ask an admin to assign one." Accurate, unhelpful, and about a record the person has never seen.
-
An administrator sets the department on the login
In a different module, on a different record, to the same value HR entered on day one. Now it works, permanently.
The refusal is the good outcome
Read step four again and notice what it is not. It is not a requisition that proceeds with no department and quietly consumes nobody's budget. Procurement insists on a department for a non-administrator and refuses without one, which is exactly the behaviour you want from a control. The cost of the split is friction on the first requisition and a confusing message — not silent unattributed spend. An administrator, by contrast, chooses the department freely and is never refused, which is a different question and the subject of Who Decides Which Department Is Spending.
How to find this in any suite you are evaluating
The general shape is worth more than this particular instance. A suite is assembled module by module over years, and the seams are where a shared fact is held twice. Departments are the easiest one to test, and the test takes ten minutes in a trial workspace.
The ten-minute cross-module test
- Create one employee, in one department, with an email address.
- Give that employee a login from inside the HR module, if the product can.
- Sign in as them and try to do the first thing that spends money — a requisition, a purchase request, an expense claim.
- If it is refused, ask which record it was reading, and go and look at that record.
- Then change the department on one of the two records and see whether the other one moves.
- Finally, ask for a report of people whose two departments disagree. The answer to that question tells you whether anyone has thought about the seam.
What AWRA OpsHub does today
- One department list, referenced by fourteen tables across HR, procurement, finance, assets, projects, the service desk and the workflow engine.
- An employment record that is genuinely separate from a login, with a nullable one-to-one link — so most of a workforce can be recorded without being given access.
- Provisioning a login for an employee from inside HR, with a role chosen at the point of provisioning, a random password, a forced first-sign-in reset and a welcome email.
- A hard refusal rather than a silent default when a non-administrator raises a requisition or a quotation request with no department on their login.
- Headcount, leave liability and payroll cost grouped by the employment record's department.
- Employee import that resolves a department by name case-insensitively and reports the row as an error when the name is not on the list.
More we can add to your workspace
- The employment record's department copied onto the login it provisions. One field in the payload that already carries the name, the email and the role.
- A reconciliation report of people whose employment department and login department disagree, so the two columns can be audited rather than assumed.
- One department per person, read by every module. The larger version of the same fix: procurement resolves the department through the employment record, and the column on the login becomes a cache rather than a second source.
- A refusal message that names the record to change and links an administrator straight to it.
- Department changes propagated on transfer, so moving somebody between departments in HR moves their requisitioning authority with them.
Where we point you to a specialist
- The separation between an employment record and a login stays. A workforce is not a user list, and collapsing the two would mean either paying for a seat per employee or losing the people who never sign in. Everything above is about making one field cross that boundary, not removing it.
- Which department a person may requisition for is a governance decision, and where an organisation wants authority and cost attribution deliberately held apart — a shared-services team that buys for others, for instance — we would keep two columns and report the difference rather than force them together.
The first item is a small, contained change with a clear test, and the reconciliation report is a query. If departmental requisitioning authority is a control you have to evidence rather than a convenience, tell us and we will come back with a written scope.
Three fixes, in the order we would do them
The cheapest fix is not the best one, and the best one is not urgent. Doing them in this order means every step is useful on its own.
Carry the department across provisioning
One field added to the payload that creates the login. It fixes every future employee and changes nothing about the ones already working.
Report the disagreements
A list of linked employee-and-login pairs whose departments differ, including the ones where the login has none. This is the number that finds the people already affected.
One source, read everywhere
Procurement resolves the department through the employment record where one is linked, so a transfer entered in HR moves requisitioning authority with it and the two columns can never drift again.
We publish scope, not dates.
Scope the department seamFive questions for any vendor selling one governed suite
Is an employee the same record as a login?
A good answer sounds like
No, and here is how they are linked.
What ours actually is
Two records, a nullable one-to-one link, one login per employee. A vendor who says yes is either charging you a seat for every employee or cannot record the ones who never sign in.
Which record does procurement read to decide the department?
A good answer sounds like
A specific answer, named without hesitation.
What ours actually is
The login, exclusively. Ask this of any suite; the answer is rarely the one the demonstration implies.
If HR moves somebody to another department, what changes downstream?
A good answer sounds like
Cost attribution, and requisitioning authority, from the same edit.
What ours actually is
Cost attribution moves. Requisitioning authority is a second edit on a second record.
Can you show me people whose two departments disagree?
A good answer sounds like
A filter and a count.
What ours actually is
Not today, and it is the single most useful number on this page.
What happens when the department is missing entirely?
A good answer sounds like
A refusal, or a named default.
What ours actually is
A refusal, on the requisition and on the quotation request. Silence here is a much worse answer than an inconvenient error.
Run the seam test on your own workspace
Take one employee, one department, one login, and one requisition. Ten minutes will tell you more about how integrated a suite really is than a day of demonstrations. If you would like us to run it with you on ours, including the parts that come out badly, ask.
Book the walkthroughFrequently asked questions
Does this affect payroll or leave?
No. Payroll, leave, attendance, headcount and cost-per-department all read the employment record, which is where HR set the department in the first place. Nothing in the HR module consults the login's department, so those figures are correct whether or not the login carries one.
What happens to a login created the normal way, rather than from HR?
The user-administration screens offer a department field, so an administrator creating a login directly can set it at the same time. The path where it is silently absent is specifically the one that starts from an employment record — which is the path most likely to be used for a person who already has a department recorded.
Is an administrator affected?
No, and that is worth knowing before you test it. An administrator chooses the department on a requisition freely and is never refused, so an evaluation run entirely from an administrator account will never see this. Test it as an ordinary member of staff.
Can I just set the department on both records and forget about it?
Yes, and for a small workspace that is the pragmatic answer: when you provision a login, set the department on it in the same sitting. The residual risk is drift — a transfer entered in HR six months later moves the cost and leaves the authority behind, with nothing reporting the difference.
How does this compare to the free-text department on a requisition?
They are two different failures on the same chain and worth reading together. This one refuses loudly and costs a person their first afternoon. The other, described in A Department That Is Only a Word, succeeds silently and costs a budget its visibility. Loud beats silent every time.
Does an HR and inventory management platform normally share a department list at all?
Sharing the list is the easy half, and most integrated suites do it — one list, one set of names, referenced from everywhere. The hard half is agreeing which record on a person is authoritative when two modules both hold the answer. That question is what separates a suite from a set of modules with the same login page, and it is worth asking specifically rather than accepting "it is all one system" as an answer.
Where does the department list itself live?
Under procurement, which is its own small surprise given that HR, assets, the service desk and finance all depend on it. We wrote that up separately in A Department Is a Name and a Description.
