Why this comes first
Every other decision in a Fusion HCM implementation rests on the enterprise structures, and they are the hardest things to change once people, payroll and history sit on top of them. A configuration mistake in absence management costs an afternoon. A mistake in the enterprise structure costs a re-implementation.
The structures answer four separate questions that organisations habitually confuse with one another: who employs this person legally, which legislation applies to them, which part of the business they cost against, and where they sit on the organisation chart. Fusion keeps these apart on purpose, because in a real group of companies they genuinely differ.
The objects, and what each one actually decides
| Object | Answers | Consequence if wrong |
|---|---|---|
| Legal Employer | Which legal entity employs the worker | Statutory reporting, contracts and end-of-service calculations attach to the wrong company |
| Legislative Data Group | Which country's payroll legislation and currency apply | Payroll cannot be processed correctly; balances are partitioned wrongly and cannot simply be moved |
| Business Unit | Which operational unit the work belongs to | Security and transaction visibility land on the wrong population |
| Department | Where the role sits organisationally | Reporting hierarchies, approvals and headcount analysis misstate the business |
| Location | Physical place of work | Statutory reporting tied to place, and some absence and time rules, apply incorrectly |
The distinction that trips up most newcomers
A Legal Employer is not the same as a Business Unit, even in an organisation where they happen to look identical on day one. The legal employer exists because a government requires someone to be accountable for this employment relationship. The business unit exists because the organisation needs to run and report operations. Merging them because they currently coincide is a decision that survives right up until the company acquires something, at which point it does not.
Similarly, a Legislative Data Group is not "the country field". It is a payroll partition. Two legal employers in the same country usually share one LDG; the same legal employer operating in two countries needs two. Getting this wrong is not a labelling error — payroll balances live inside the partition, and moving them later is a data migration, not a correction.
Jobs and positions
A job is a generic role that exists independently of headcount: "Financial Analyst". A position is a specific seat: "Financial Analyst, Cairo Finance, reporting to the Finance Manager". Position management gives tighter control over headcount and budget, at the cost of a great deal more configuration and ongoing maintenance.
Organisations that manage headcount at board level and hire against approved seats generally want positions. Organisations that hire flexibly and reorganise often usually find positions become a source of stale data nobody maintains. Choose against how the organisation actually behaves, not against how it describes itself in a workshop.
What to take from this lesson
- The five objects answer different questions; resist collapsing them because they currently coincide.
- Legislative Data Group is a payroll partition, not a country label.
- Structures are expensive to change once history exists — spend the design time before go-live, not after.
- Positions are a control mechanism with a maintenance cost. They are a decision, not a default.