Core HR — Module Case

Alt text: Flowchart of the setup sequence with two loop-back paths: a department with no business unit returns to the business unit, and a payroll relationship pointing at the wrong legal entity returns to the legal entity rather than to the assignment.

Reported time reaches payroll only if seven configuration steps were performed in dependency order: legal entity, business unit, department, location, worker time entry profile, assignment. Two of those steps are decisions rather than actions, and both can fail. A business unit whose legal entity does not exist loops back to the entity step rather than continuing. A department with no valid business unit loops back to the business unit. The final decision is the expensive one: it asks whether the payroll relationship names a legal entity that employs in the worker country, and a no returns all the way to the legal entity, because the assignment is correct and the entity it names is not. That case produces a worker who exists, accrues entitlement, enters time, has it validated, transferred and received by payroll, and is never paid — with no error reported anywhere in the chain.

Alt text: Swimlane diagram with four lanes across four phases: the HCM administrator owns structure and worker setup, the worker enters time, the system validates and routes, and payroll appears only in the final phase.

Four lanes, four phases, time running left to right. The HCM administrator lane is busy for the first two phases and then idle: it creates the legal entity, business unit, department and location, then the worker time entry profile and assignment, and it does nothing during time entry or pay. The worker lane acts once, entering time. The system lane validates, calculates and transfers during the time phase, then performs the single most dangerous action in the whole process — delivering time across the bridge to payroll. The payroll lane is empty for three of the four phases and acts only at the end, producing the payslip line from whatever arrived. This is the diagnostic lesson of the picture: every step before the last column is inside a system the administrator controls and can inspect, and the last column is the only boundary where a defect can occur without anything reporting an error. A learner who internalises the shape of this diagram will start their investigation at the boundary rather than in payroll.

Alt text: Relationship diagram: one job fans out to three positions in three business units, each position has its own assignments, and one person holds two of those assignments.

Three levels, read top to bottom. At the top is one job definition, carrying its job set, its code and its valid grades. It fans out to three positions, each defined within a single business unit and belonging to one department or organization with its own unique name. Each position has assignments beneath it, and the person sits at the bottom connected to two of them, so one person holds two assignments at once and remains one person record. The lifetime rule is the consequence of the shape: the job is a reusable definition that no exit touches, the position continues to exist when it has no holder so that direct reports keep reporting to the role, and the assignment is the only record that ends. Generated assignment numbers prefix the person number with a letter for the worker type and a suffix for later assignments of the same type, which is why two roles for one person are E45678-1 and E45678-2 rather than a duplicate worker.

Alt text: Lifecycle table: the job is unchanged by an exit, the position survives empty and keeps carrying the reporting line, and only the assignment ends.

One exit event and three records with three different outcomes, only one of which is the person. The job is a reusable definition, so an exit does not touch it: the same job describes the same work for whoever fills it next. The position continues to exist when it has no holder, and that is the part that matters operationally, because the position is what carries the reporting line, so direct reports stay attached to the role and a replacement manager is assigned to the existing position rather than to a new one. The assignment is the only record that ends: its status changes and it stops being eligible for payroll processing. An exit checklist therefore has to decide record by record rather than person by person, and the specific mistake this table exists to prevent is deleting the empty position on the grounds that nobody is in it.

Alt text: Work relationship states: created by one of five processes, designated primary or nonprimary, terminated, then inactive while the person record remains active.

A work relationship moves through four states, and the transitions are the rules. Created: one of five processes — Hire, Rehire, Global Transfer, Global Temporary Assignment, or Create Work Relationship — brings it into existence, and the worker type and legal employer are chosen in that moment and cannot be changed afterwards. Designated: a person can have only one primary work relationship; the first work relationship is primary by default, while pending worker and offer work relationships are created nonprimary by default, and a nonprimary relationship can be promoted with the Work Relationship quick action on the My Client Groups tab. Terminated: the person leaves — but the primary work relationship cannot be terminated until a different primary has been selected, because a person cannot be without a primary work relationship at any time. That is the stuck state, and the way out is selection rather than persistence. Inactive: the work relationship is closed while the person record remains active, and a rehire identifies the existing person and creates a new work relationship rather than reopening the inactive one. The worker type is recorded as a single letter in the assignment and period-of-service tables — P for pending worker, E for employee, C for contingent worker, N for nonworker, O for offer — so the type a query reads was fixed at a door that no longer opens.

Alt text: Functional roles deciding what a user can do, and data roles with security profiles deciding what data they can see, with the phase rule for where the tasks live.

Oracle HCM Cloud security is role-based, and it has two halves. The functional half is job, abstract and duty roles, which decide what a user can do. The data half is HCM data roles and HCM security profiles, which decide what data a user can see: person security profiles secure access to person records, and organization and other security profiles secure access to organizations, positions, document types, legislative data groups, payrolls and payroll flows. The diagnostic value of the split is that the two failures present differently — a user whose function roles are wrong cannot open the page at all, while a user whose data roles are wrong opens it and finds it empty, and both say "I do not have access". Beneath both halves sits the phase rule for where the settings live: during implementation, security-related tasks are performed from a functional area task list or implementation project; after implementation, most are performed on the Security Console, and the exceptions are named where they apply — workers are hired in the New Person work area, never on the console. Two further rules complete the model. When the role hierarchy changes, the data security policies of data and abstract roles must be regenerated, so a saved hierarchy change is only half applied until it is. And location-based access is enabled by listing authorized IP addresses, with selected roles that can be made public, so a refusal from one network while every role is granted is a location problem rather than a role problem.

Alt text: The legal, managerial and functional structures as three axes, with the records each is implemented with and the functional areas that configure them.

An enterprise is modelled with three fundamental structures — legal, managerial and functional — and they are axes rather than layers. The legal structure is implemented with legal entities: registered in their jurisdictions, able to own and trade assets and to employ people there, and carrying the responsibilities that registration assigns — statutory and external reporting, compliance with legislation and regulations, income and transaction taxes, and VAT collection on behalf of the taxing authority. The management structure is implemented with divisions and business units and is reflected in the chart of accounts. The functional structure is implemented with departments and organizations, including sales, marketing, project, cost and inventory organizations, and its expenses land directly on the income statement. The axes deliberately do not line up: one business can be operated by legal entities in several countries, and one legal entity can run several businesses, which is why a single tree cannot answer all three questions and the first statutory report that wants a different grouping exposes the difference. The configuration is split to match the structures: legal entity setup tasks sit in the Legal Structures functional area, business unit setup in Organization Structures, and department, division, trees, jobs, positions and other organizations in Workforce Structures. One exception is worth memorising on its own: payroll statutory units, legal employers and tax reporting units are created from the Manage Legal Entity task in Setup and Maintenance, but revised with Manage Legal Entity HCM Information in the Workforce Structures work area — a record whose creation and revision live in different work areas.

Alt text: Person, work relationship and assignment as containment, with assignment-level security as the unit of visibility.

Three records answer three questions about one person. The person is who they are. The work relationship binds them to one legal employer under one worker type, fixed from creation, and must hold at least one assignment. The assignment carries the role — job or position, pay, compensation, managers, working hours, location — and its status decides payroll eligibility. Two primary rules govern the pair and can disagree: a person has one primary work relationship, and each work relationship holds one primary assignment — including inside pending worker and offer relationships, which are created nonprimary while the assignments within them are still created primary. Security stops at the assignment, not the person: worker assignments are secured by assignment-level security, so a line manager reaches only the assignments of workers reporting to them and an HR specialist only within their area of responsibility. One worker with two assignments can therefore be correctly visible to two different managers, and a missing assignment in one manager’s view is not evidence it was deleted. Two projected date fields complete the picture and do nothing: the projected termination date on the work relationship table and the projected assignment end date on the assignment table are for information purposes only and have no effect on application processing.