Oracle Fusion Cloud HCM gives HR teams one system for people data, from hire to retire. Getting there depends on doing the core setup in the right order and making a few structural decisions early. This guide sets out the sequence Egisedge follows, based on our HCM core setup playbook, and the pitfalls we watch for.
It is written for HR leaders, HCM consultants and CIOs. For field-level detail, use the Oracle Fusion Cloud HCM documentation and Oracle's HCM implementation playbooks.
Decisions to make before configuration
| Decision | Options | What it affects |
|---|---|---|
| Legal employers | One per employing legal entity | Payroll, statutory reporting, contracts |
| Legislative data groups | One per country or payroll legislation | Payroll, absence, elements |
| Job or position model | Job-based, or position-based with seat control | Headcount, budgeting, requisitions |
| Grade structure | Grades, grade steps, grade ladders | Pay scales, progression |
| Employment model | Two-tier or three-tier | How assignments and contracts are held |
| Security approach | Area of responsibility, manager hierarchy, or both | Who sees whom |
| Approval routing | Supervisor, position, HR representative | Every self-service transaction |
Write these down, agree them with HR, payroll and finance, and do not start the build until they are signed.
The core HCM setup sequence
1. Enterprise, legislative data groups and legal employers
Create the enterprise, then legislative data groups (LDGs) for each country or payroll legislation. Create legal entities and designate them as legal employers where they employ people. Associate each legal employer with its LDG. If you also run Oracle Financials, agree legal entities with the finance team so both sides use the same ones.
2. Workforce structures
Build the organisation in this order:
- Business units.
- Departments, with the department tree if you report by hierarchy.
- Locations.
- Job families and jobs.
- Grades and grade ladders.
- Positions, if you use a position model.
Keep names consistent and meaningful. These structures appear on every report and every self-service screen.
3. Person and employment settings
Configure person name styles, national identifier types, lookups, and the employment model. Add descriptive flexfields only for data you will genuinely use. Every extra field is a data quality cost later.
4. Security
Design roles and security profiles early. Define person, organisation and position security profiles, then create HCM data roles that combine a job role with those profiles. Test with real users: an HR business partner should see their population and nobody else's. Security designed in the last month of a project is the most common cause of UAT delays.
5. Approvals and workflow
Configure approval rules for key transactions: hire, promotion, transfer, salary change, termination, absence. Resist the urge to copy every rule from the legacy system. Fewer, clearer rules are easier to maintain and audit.
6. Absence management
Set up absence types, absence plans, accrual rules, and the link to payroll if absence affects pay. Test accrual calculations over a full year using sample employees with different join dates.
7. Payroll
Where Oracle payroll is in scope, define elements, balances, payroll definitions, and costing. Plan for payroll parallel runs, comparing Oracle output with the legacy payroll employee by employee. Budget more time for this than you think.
8. Load workers with HCM Data Loader and reconcile
Load work structures, then workers and their assignment history using HCM Data Loader (HDL). Run several mock loads before cutover. After each load:
- Reconcile headcount by legal employer, department and location.
- Check a sample of workers field by field against the source.
- Review HDL error reports, fix the source data and reload.
The same principles as our FBDI data migration validation guide apply: counts, balances, samples and sign-off.
Stage checklist
- Design decisions signed by HR, payroll and finance
- LDGs and legal employers created and associated
- Workforce structures built and reviewed by HR
- Security profiles and data roles tested with real users
- Approval rules configured and tested end to end
- Absence accruals tested over a full year
- Payroll elements and costing set up; parallel runs planned
- HDL mock loads run; headcount reconciled
- Quarterly update regression pack in place for HCM
Common pitfalls
- Dirty legacy data. Missing join dates, duplicate people and inconsistent job titles surface late. Profile data at the start.
- Too many flexfields. Only add fields that someone will maintain and report on.
- Security left late. Build it alongside structures.
- Copying old approvals. Simplify first, then configure.
- Underestimating payroll. Parallel runs take several cycles to get to zero differences.
- No plan for quarterly updates. HCM is updated every quarter like the rest of Fusion. See how to test Oracle Fusion quarterly updates.
Planning the HCM cutover
HCM cutover has a timing problem that finance cutover does not: people keep joining, moving and leaving while you migrate. Plan for it:
- Set a data freeze date for bulk history, and a short window for late changes.
- Load a delta of new joiners, transfers and leavers just before go-live.
- Align go-live with a payroll period boundary, so the first Oracle payroll starts cleanly.
- Reconcile headcount again after the delta load and before opening self-service.
- Keep read-only access to the legacy system for queries during hypercare.
Getting users ready
Self-service only works when employees and managers use it. Plan short, task-based training: how to request absence, how to approve, how to update personal details. Oracle's HCM bite-size learning is useful for the HR team and key users.
Where AI is heading in HCM
Oracle is adding AI features and agents across Fusion HCM, and many HR teams are looking at agents for employee questions and policy checks. These work best on a clean HCM foundation: accurate structures, security and data. See our article on AI agents for Oracle Fusion Finance and HCM.
How Egisedge helps
Egisedge Technologies is an Oracle Partner delivering Oracle Fusion Cloud HCM. Our HCM practice is led by Jafar, our HCM Director, and our Oracle HCM references include Al Shirawi Group, Abu Dhabi Healthcare, Zayed University and Almana Group (Qatar). We also delivered an HR solution for Policy Bazaar. AI Agents for HCM is one of our products in development. We work from India with teams covering GCC, UK/Europe, US and Australia/NZ working hours.
Planning an Oracle HCM implementation or fixing an existing one? Email info@egisedge.com or book a demo with our team.
Frequently asked questions
What is the setup order for Oracle HCM Cloud core HR?
Start with the enterprise, legislative data groups and legal employers, then workforce structures (business units, departments, locations, jobs, grades, positions), then person and employment settings, security, approvals, absence and payroll. Load workers with HCM Data Loader last and reconcile headcount.
What is HCM Data Loader?
HCM Data Loader (HDL) is Oracle's bulk loading tool for HCM data. It loads business objects such as workers, assignments and work structures from .dat files, and is used both for migration and for ongoing bulk updates.
Should we use positions in Oracle HCM?
Use positions if you control headcount and budgets by seat, as many public sector, healthcare and education organisations do. If you manage by job and department, a job-based model is simpler to run.
What are the biggest risks in an Oracle HCM implementation?
Poor legacy data quality, late security design, complex approval rules copied from old systems, and underestimating payroll parallel runs are the most common causes of delay.
Talk to Egisedge about HCM
Tell us where you are and we'll reply within one working day with next steps.