Core HR
The Worker Lifecycle: What a Work Relationship Can and Cannot Survive
Five processes create a work relationship, two of its values are fixed forever, one primary rule decides what you may terminate, and a rehire never reopens what a termination closed.
Learning objectives
- 1.Name the five processes that create a work relationship
- 2.Explain why the worker type and legal employer cannot be changed, and what changing either requires
- 3.State the primary work relationship rules and what they prevent you from doing
- 4.Explain what a rehire actually does to the person record and the terminated work relationship
Why this matters
A work relationship looks like a form field, and it behaves like a decision. It is the record that binds a person to one legal employer under one worker type, and the moment it is created those two values stop being editable. Almost every lifecycle problem that reaches support — a worker under the wrong employer, a contingent worker who should have been an employee, a transfer that will not take — is somebody discovering that a decision made at creation time cannot be amended at correction time.
If you skip this: A work relationship created under the wrong worker type or legal employer cannot be corrected in place. It has to be cancelled and created again, and everything that was attached to it has to be reattached.
What it is, why it exists, what breaks
What it is
A work relationship is created by one of five processes — Hire, Rehire, Global Transfer, Global Temporary Assignment, or Create Work Relationship — and you select the worker type and legal employer when you create it. Neither can be changed afterwards.
Why it exists
The binding is the point. Worker type and legal employer decide which rules, which payroll and which reporting apply to the person, so they are properties of the relationship rather than of the person — and a property of a record that everything else keys on is not safely editable.
What breaks without it
When the wrong worker type or legal employer is chosen, the fix is not an edit. The work relationship must be cancelled and the process repeated, with the person re-created under the correct binding. Oracle points at two My Oracle Support documents for that procedure rather than describing it on the page.
Source: COREHR-WR-013, COREHR-WR-016
The work relationship lifecycle
A work relationship moves from creation to inactive through four states, and each transition is a rule about what may happen next.
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.
What to take from this: The stuck state is the teaching point. A primary work relationship cannot be terminated while it is the only primary, so the way out of "this person must leave" is not the terminate button — it is selecting a different primary first, or accepting that the person is not leaving this relationship at all. The rehire arrow closes the loop: it leaves the terminated relationship inactive and starts a new one, which is why a rehired worker is not the same record they were before.
Source: COREHR-WR-016, COREHR-WR-018, COREHR-WR-019
The contingent worker who should have been an employee
A new contractor is onboarded through the Hire process the week before their contract is renegotiated into a permanent role. Their work relationship was created with worker type Contingent Worker and the correct legal employer. HR now needs them recorded as an employee, with everything that follows from that.
- 1.Someone opens the work relationship looking for a worker type field to change, and there is nothing to change.
- 2.The worker type was fixed when the work relationship was created, and the page states it cannot be changed afterwards.
- 3.The route Oracle documents is to cancel the work relationship and repeat the creation process with the correct worker type.
- 4.The re-created person inherits the reporting and history that the person record carries, not the work relationship that was cancelled.
Takeaway: A worker type is not an attribute you can amend; it is a binding you choose once. Deciding it correctly at creation is cheaper than any route out of deciding it wrong.
Source: COREHR-WR-013
Configuration model
Navigation paths
My Client Groups > Work Relationship quick action — to make a nonprimary work relationship the primary oneCOREHR-WR-018
Objects
Work relationship
Binds the person to one legal employer under one worker type, and holds the assignments that carry the role details.
Risk if wrong: A wrong worker type or legal employer cannot be edited; the relationship is cancelled and re-created, and anything attached has to be reattached.
Worker type
One of Pending Worker, Employee, Contingent Worker, Nonworker or Offer, recorded as P, E, C, N or O in the assignment and period-of-service tables.
Risk if wrong: Support queries that read the type letters from the database find a value nobody remembers choosing, because it was fixed at creation.
Primary designation
Names the one work relationship that reporting, pay and benefits read when they need a single answer for the person.
Risk if wrong: A nonprimary relationship is mistaken for a duplicate, or the primary is terminated while it is the only one and the termination is refused.
Constraints
- A work relationship is created only by Hire, Rehire, Global Transfer, Global Temporary Assignment or Create Work Relationship.
- The worker type and legal employer are selected at creation and cannot be changed afterwards; changing either requires cancelling the work relationship and repeating the process.
- A person can have only one primary work relationship. The first work relationship is primary by default, except that a pending worker work relationship is created as nonprimary by default, and an offer work relationship is also nonprimary by default.
- You cannot terminate the primary work relationship until you have selected a different primary, because a person cannot be without a primary work relationship at any time.
- Each work relationship must have at least one primary assignment, and where a person has several work relationships the overall primary assignment is the primary assignment in the primary work relationship.
- Nonworkers cannot be selected as Department Managers or Cost Center Managers, are not displayed on the position hierarchy, and are not counted as incumbents in the position incumbent validation.
- The Offer worker type is available only with Oracle Recruiting Cloud and an offer created for the candidate, and a pending worker work relationship cannot be created for an existing worker who has a job offer in Oracle Recruiting Cloud.
Source: COREHR-WR-013, COREHR-WR-016, COREHR-WR-017, COREHR-WR-018, COREHR-NWK-020, COREHR-WR-021, COREHR-ASG-012
Common mistakes
Wrong: Looking for an Edit action on the worker type or legal employer.
Symptom: The field the correction needs does not exist, and the correction is escalated as a missing permission.
Fix: Neither value can be changed after creation. The documented route is to cancel the work relationship and repeat the creation process.
Wrong: Terminating the primary work relationship of a person who has another one.
Symptom: The termination is refused, and the refusal is read as a data problem in the person record.
Fix: A person cannot be without a primary work relationship. Select a different primary first — the Work Relationship quick action on the My Client Groups tab makes a nonprimary relationship primary — then terminate.
Wrong: Expecting a rehire to reopen the terminated work relationship.
Symptom: The rehired worker appears with a new work relationship and the old one stays inactive, which is mistaken for a duplicate person record.
Fix: The termination makes the work relationship inactive while the person record remains active. The rehire identifies the existing person and creates a new work relationship, so two inactive-plus-active relationships after a rehire is correct behaviour.
Wrong: Reading a nonworker as a person who appears in the organisation charts.
Symptom: A volunteer is missing from the position hierarchy, or a department manager assignment is refused for someone who seems eligible.
Fix: Nonworkers are not displayed on the position hierarchy, cannot be Department or Cost Center Managers, and are not counted as position incumbents.
Diagnosing it
Symptom: A work relationship cannot be terminated, or a worker appears to be missing from reporting that reads their primary assignment.
Category: effective dating
- 1.
Is the work relationship you are terminating the person's primary one, and is there another work relationship to promote?
If no: The termination is correctly refused. A person cannot be without a primary work relationship at any time, so select a different primary first.
Evidence to capture: The primary designation on every work relationship the person holds
- 2.
Is the worker type on the relationship the one the process expected — Employee rather than Contingent Worker, read as E rather than C in the tables?
If no: The reporting is reading the correct record and the type is wrong. The fix is cancelling and re-creating the work relationship, not editing it.
Evidence to capture: The ASSIGNMENT_TYPE letter in PER_ALL_ASSIGNMENTS_M for the assignment in question
- 3.
Is the person a pending worker whose work relationship was created as nonprimary by default?
If no: A pending worker relationship is nonprimary from creation, so primary-based reporting will not see it until the hire is finalized or the primary is reassigned.
Evidence to capture: The primary flag on the pending worker work relationship
Confirm: Confirm the primary designation, the worker type letter and the process that created the relationship, and that the reporting in question reads the primary work relationship rather than a named one.
Recall
Name the five processes that create a work relationship, state the two values that are fixed from creation, and say what a rehire does with the terminated relationship and the person record.
Answer shape: Hire, Rehire, Global Transfer, Global Temporary Assignment and Create Work Relationship. The worker type and the legal employer are fixed from creation and can only be changed by cancelling the work relationship and repeating the process. A rehire leaves the terminated work relationship inactive, keeps the person record active, and creates a new work relationship.
Memory hook: Five doors in, no door back. Type and employer are set at the door. One primary at all times, and a rehire is a new relationship, not a reopened one.
Source evidence
The five creation processes, the worker type letters, the primary work relationship rules, the rehire behaviour, the nonworker restrictions and the Recruiting Cloud constraints were read from the Work Relationships page on 2026-10-09. The definition and the immutability of the worker type and legal employer were already recorded as COREHR-WR-013 from the same page on 2026-10-05.
Release scope: FA Latest
Recorded gaps
- The page references My Oracle Support documents 1595810.1 and 1633860.1 for changing the worker type or legal employer. Those are document IDs, not content: they have not been read, so this lesson names the route and does not describe the procedure.
- The page describes converting a pending worker to the proposed worker type when the hire is finalized, and notes a Redwood change to where the Include for Automatic conversion attribute lives. The conversion timing is not described in enough detail on the page read to be taught as behaviour, so this lesson does not assert it.
- The page names the PER_ALL_ASSIGNMENTS_M, PER_PERIODS_OF_SERVICE, PER_NON_WORKER_TYPES and SYSTEM_PERSON_TYPE tables and lookups. The letters are taught; the wider contents of those tables are not.
Related concepts
- Assignmentdepends on
The work relationship holds the assignments, and must have at least one primary assignment at all times.
- Legal entity and legal employerdepends on
The legal employer is half of what a work relationship binds, and the half that cannot be edited afterwards.
- ORC to Core HR bridgereferenced by
The Offer worker type exists only with Oracle Recruiting Cloud, and a pending worker relationship cannot be created for someone who already holds a Recruiting Cloud job offer.
Self-check
An auto-graded assessment is attached to this lesson: assessment-core-hr-worker-lifecycle
Lesson progress
Checking your progress…