HCM Studio
Sign in

Core HR

Jobs, positions and the assignment that joins them

Three records with three different lifetimes. Which one you model the role on decides whether it survives the person, and which one carries the person decides how many payslips a worker can have.

intermediate16 min readFor HCM administrators implementing Oracle Fusion Cloud HCM, Support analysts diagnosing a worker record, HCM Functional Consultants new to work structuresRelease FA Latest

Learning objectives

  1. 1.State what a job, a position and an assignment each hold, and which survives the person leaving
  2. 2.Explain the jobs-only versus jobs-and-positions decision and the determinants Oracle gives for it
  3. 3.Explain where a grade is chosen and why the valid-grade list is advisory by default
  4. 4.Diagnose a worker in a grade that does not match the role they are in

Why this matters

Three records describe the same piece of work, and they do not have the same lifetime. A job is a reusable definition. A position is one slot that exists whether or not anybody is sitting in it. An assignment is one person doing that work on particular dates. Confusing them is not a tidiness problem; it decides what happens on the day somebody leaves.

If you skip this: Model the role on the person and the role disappears with them. Model it on the job and every structural change means rewriting a job definition that other people are already using.

What it is, why it exists, what breaks

What it is

A job is a reusable role definition carrying an effective start date, a job set, a name and a code that must be unique within its set, plus the grades valid for it. A position is one instance of a job: a specific role that can be managed independently of the person in it, belonging to one department or organization with a unique name. An assignment is the dated link from a person to that work, carrying job or position, pay, compensation, manager, working hours and location.

Why it exists

Splitting the reusable description from the durable slot from the individual record is what lets the same role be described once, filled more than once, refilled after a vacancy, and attached to different people in different places without being redefined each time.

What breaks without it

A structure built without positions has nowhere to record that a role still exists while it is empty. A structure built without the job as a reusable definition ends up with a job set full of near-identical definitions, one per incumbent. A structure that treats the assignment as the role cannot answer "how many of these do we have" without reading every person.

Source: COREHR-JOB-001, COREHR-POS-004, COREHR-ASG-009

Job, positions and assignments

Read top to bottom. One definition, three slots, four records, one person — and the arrows are the point, because a job fans out to positions while a person fans in to 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.

Two assignments on one person is not duplication. It is one person holding two roles.

What to take from this: Read the fan-out before the fan-in. One job produces many positions, and each position produces many assignments, so the job is the only level where a rule written once applies everywhere. The fan-in is the other half of the lesson: one person reaches two assignments and therefore two lines of responsibility, two grades and two reporting lines, which is legal and is the shape most support tickets about "duplicate workers" are really about.

Source: COREHR-POS-006, COREHR-ASG-011

The reporting line that disappeared when a manager resigned

An organisation models roles as positions. A regional payroll manager resigns. The HR shared service team, acting on the exit checklist, ends the assignment and then deletes the now-empty position, because there was nobody in it. The manager reported to had eight direct reports.

  1. 1.The eight reports still exist as workers with active assignments, and each one was managed through that position.
  2. 2.Their manager field now resolves to nothing, and the approval hierarchy that routes their absence and time approvals has no approver at that level.
  3. 3.Time cards for that population stop routing for approval, which produces the familiar symptom of a card sitting unsubmitted for weeks.
  4. 4.The fix is not in Time and Labor. The position has to exist again, and the replacement manager has to be assigned to it.

Takeaway: The position is the durable record and the assignment is the temporary one. Deleting the empty one destroys the reporting line, and every downstream approval that depended on it fails with no error naming the cause.

Source: COREHR-POS-005

What each record does when the person leaves

One event, three records, and only one of them is the person. Read across a row to see what each record does before and after the exit.

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.

End the assignment and leave the position. Deleting the empty position takes the reporting line with it.

What to take from this: Three records, one exit, three different outcomes — and only one of them is the record that ends. The job definition is untouched by anybody leaving, the position survives as an empty role that still carries the reporting line, and the assignment is the only record whose status changes. This is the picture to hold when an exit checklist asks you to clean up: decide per record, not per person.

Source: COREHR-ASG-010

Configuration model

Navigation paths

Objects

Job

The reusable definition of the work: an effective start date, a job set, a name and a code, plus the grades that are valid for it.

Risk if wrong: A rule written against the job applies to every holder at once, so a wrong job code or a wrong valid-grade list is a population-wide defect.

Job set

The grouping that makes codes meaningful. A code may repeat across sets, which is how the same code can exist for a US set and a UK set.

Risk if wrong: A code created in the Common set cannot then be created in any other set, so a careless first move constrains the whole enterprise.

Position

One slot for the role inside one department or organization, with a unique name, which can be managed independently of whoever holds it.

Risk if wrong: An empty position deleted during an exit takes the reporting line with it, and the failure appears in Time and Labor approvals rather than in Core HR.

Grade

The level attached to the role. One or more grades are defined as valid for each job and for each position, and a payroll element can reference the grade in its eligibility.

Risk if wrong: An element scoped to a grade silently stops matching the worker population it was written for, and the symptom is a missing pay element rather than an error.

Assignment

The dated, person-specific record: job or position, pay, compensation, manager, working hours and location, with a status that decides payroll eligibility.

Risk if wrong: One assignment per role means a person who genuinely holds two roles cannot be represented, and the second role has to be faked somewhere else.

Work relationship

The link between a person and a legal employer, carrying the worker type. Every assignment belongs to one, and each relationship needs at least one primary assignment.

Risk if wrong: Worker type and legal employer cannot be changed after creation. Getting it wrong at hire means cancelling and recreating the relationship.

Position synchronization

Inheritance of values in an assignment from the values on the associated position, so a change to the position propagates instead of being retyped per person.

Risk if wrong: Off by default, and enabling it part-way through an implementation leaves existing assignments unsynchronised until they are flagged and the process is run.

Constraints

  • A job code must be unique within its job set, and a code used in the Common set cannot be created in any other set.
  • A position name must be unique, and a position belongs to one specific department or organization.
  • A work relationship must have at least one assignment, and every work relationship must have at least one primary assignment.
  • Assignment status controls payroll eligibility, and it is set to Active - payroll eligible when the assignment is created.
  • Worker type and legal employer cannot be changed after a work relationship is created; it has to be cancelled and created again.
  • Valid grades are advisory unless PER_ENFORCE_VALID_GRADES is set to Yes, and Oracle documents its default as No.

Source: COREHR-JOB-001, COREHR-GRADE-008, COREHR-ASG-012, COREHR-WR-013, COREHR-SYNC-014, COREHR-WS-015

Common mistakes

Wrong: Creating a job for each person rather than one job and a position per slot.

Symptom: The job set fills with near-identical definitions that differ only by a name, and any rule written against a job reaches exactly one person.

Fix: One job describes the work; a position describes the slot; the assignment says who fills it. A duplicate-looking job is the signal that the modelling is wrong, not that the work is different.

Wrong: Treating the grades listed against a job as a constraint on the assignment.

Symptom: A worker sits in a grade that is not valid for their job or position, and nothing anywhere objects.

Fix: PER_ENFORCE_VALID_GRADES defaults to No, so any grade can be selected. Set it to Yes if the list is meant to bind, and audit existing assignments before turning it on.

Wrong: Deleting the position as part of an exit because it is empty.

Symptom: The reporting line disappears and time or absence approvals for that population stop routing, with no error naming the cause.

Fix: End the assignment and leave the position. An empty position is the record that says the role still exists and who reports to it.

Wrong: Assuming one worker means one assignment because the person record shows one row.

Symptom: A second role is stored somewhere other than an assignment, or the person is duplicated to hold it, and the two roles disagree with each other.

Fix: A work relationship must have at least one assignment and the legal employer may allow several. Number them with the generated sequence and decide which is primary.

Wrong: Changing worker type or legal employer on an existing work relationship.

Symptom: The change is refused, and the only documented route is to cancel the relationship and create it again.

Fix: Worker type and legal employer are chosen when the work relationship is created and are not editable afterwards. Verify both before hiring rather than after.

Diagnosing it

Symptom: A worker is paid at the wrong level, or a payroll element scoped to a grade does not reach them.

Category: configuration

  1. 1.

    Is the site profile option PER_ENFORCE_VALID_GRADES set to Yes for this tenant?

    If no: This is the expected state, and it is the answer in most cases. The documented default is No, so the valid-grade list is documentation rather than a constraint.

    Evidence to capture: Site profile value for PER_ENFORCE_VALID_GRADES

  2. 2.

    If positions are in use, does the grade on the assignment match a grade valid for that position?

    If no: The job grades only become the default grades of a position; the position list can be adjusted, so check the position rather than the job.

    Evidence to capture: Valid grades on the position, and the grade on the assignment

  3. 3.

    Is the assignment the primary assignment in the primary work relationship?

    If no: Single-assignment reporting and elements scoped to the primary record will read the other assignment. This is a selection problem, not a pay problem.

    Evidence to capture: Primary assignment for each work relationship

  4. 4.

    Is the assignment status one that is eligible for payroll processing?

    If no: A suspended or inactive assignment still exists and still appears in reports, but it is not processed, which looks exactly like missing pay.

    Evidence to capture: Assignment status for the period in question

Confirm: Confirm by checking that the payroll element whose eligibility references the grade now matches the worker. If it still does not, the grade is not the cause and the element criteria are the next place to look.

Recall

State what a job, a position and an assignment each hold, then say which of the three survives the person in the role leaving.

Answer shape: The job holds the reusable definition: effective start date, job set, name and a code unique within the set, plus the grades valid for it. The position holds one instance of that job: a specific role that can be managed independently of the person in it, belonging to one department or organization with a unique name, defined within one business unit. The assignment holds the dated, person-specific record: job or position, pay, compensation, manager, working hours and location, with a status controlling payroll eligibility. On an exit the job is untouched and the position survives as an empty role that still carries the reporting line; only the assignment ends.

Memory hook: The job is the noun, the position is the chair, the assignment is the person sitting in it. When the person leaves, the chair stays.

Review these concepts

Source evidence

Ten Oracle pages were read directly on 2026-10-05 and are cited rather than reproduced. The job, position, grade, assignment and work relationship statements come from the Jobs, Considerations for Using Jobs and Positions, Job and Position Structures, Examples of Positions, Assignments and Work Relationships pages and the Talent Management grades page. The recommendation that a configuration exercise should reason about what happens when somebody leaves is this academy model, not an Oracle statement, and is recorded here so a learner knows which part to trust in a support call.

Release scope: FA Latest

Recorded gaps

  • No page read states how many assignments a person may hold. Oracle states that a work relationship must have at least one assignment and that the legal employer may allow several in one relationship; any practical maximum is tenant configuration and is not documented on these pages.
  • The navigation paths in this lesson are assembled from the Workforce Structures work area and the task names the pages state. The full menu breadcrumb is not published on the pages read, so verify it in a tenant before putting it in a work instruction.
  • Oracle publishes per-industry and per-turnover-scenario guidance for the jobs or positions decision, but no single page states it as a reversible configuration option. This lesson teaches it as the implementation decision Oracle says it is, not as a switch you can flip later.
  • The Oracle documentation consulted states that a vacancy must be created manually when position synchronization is used and an incumbent moves out of the position. Whether the same is true where synchronization is not in use was not confirmed on these pages and is not taught here.

Related concepts

  • Jobteaches

    The reusable role definition, and the level at which a rule written once reaches every holder.

  • Positionteaches

    The durable slot that survives its holder and carries the reporting line.

  • Assignmentteaches

    The dated person-specific record, and the only one of the three that ends on an exit.

  • Departmentdepends on

    A position belongs to one specific department or organization, so the department has to exist first.

  • Business unitdepends on

    A position is defined within one business unit, unlike a job which can live in the Common set.

  • Payroll relationshiptroubleshoots

    Assignment status decides payroll eligibility, which is the first boundary this lesson hands to the next one.

Self-check

An auto-graded assessment is attached to this lesson: assessment-core-hr-jobs-and-positions

Start self-check

Lesson progress

Checking your progress…

Jobs, positions and the assignment that joins them · Oracle Fusion Cloud HCM · HCM Studio by Digi Tracks · www.digitracks.net · contact@digitracks.net

Claims: COREHR-JOB-001, COREHR-POS-004, COREHR-ASG-009, COREHR-POS-005, COREHR-GRADE-008, COREHR-ASG-012, COREHR-WR-013, COREHR-SYNC-014, COREHR-WS-015

Oracle, Oracle Fusion Cloud HCM and the Oracle logo are trademarks of Oracle Corporation. HCM Studio is an independent training product, not affiliated with or endorsed by Oracle.