12.4 Terminations with Position Management and Position Workflows

12.4 Terminations with Position Management and Position Workflows

Quick Answer: When a termination is saved, PM runs follow-up processes: hierarchy adaptation, matrix-to-job relationship sync, To Be Hired adaptation, and position deactivation. Direct reports can be reassigned by position hierarchy. Position changes are protected by workflows, which can route to position relationships (position, parent position, grandparent position) or position-based dynamic roles.

Termination in Position Management

Terminating ends the employment and sets the employee to inactive. With Position Management, employees can be terminated from the Position Org Chart, with the reason, the date, and details such as the final salary date.

Follow-Up Processes

When a termination is saved through the UI (Centralized Services) and succeeds, these processes run in the background, in this order:

1. Hierarchy adaptation: with the position hierarchy leading, transfer direct reports according to the position hierarchy. This runs in the background when Reassign Direct Reports… is Yes – Always, otherwise synchronously.
2. Matrix relationships to job relationships sync: relationships of a terminated job-relationship manager move to another manager. The default is everyone to the upper manager, with options for a different manager, ending all relationships, or individual transfer.
3. To Be Hired status adaptation for the position.
4. Deactivate position, if chosen.

If a process fails, the initiator gets an e-mail and an admin alert is created, and later processes do not run. Retriggering the admin alert reruns the failed process and all later ones.

Transferring Direct Reports

In Position Management Settings > Hierarchy Adaptation, Reassign Direct Reports According to Position Hierarchy on Termination Screen:

Key points:

• Everyone to upper manager is a user decision independent of the position hierarchy. Everyone according to position hierarchy chooses the incumbent of the next available position.
• It works only if all direct reports and the manager have positions and the supervisors are in sync with the position hierarchy. Otherwise manual correction is needed.
• Only direct reports are transferred, not positions. The leaver's position stays on the chart, now empty. To move positions, do it manually or with a mass change.
• If the target position has several incumbents, reports go to the first incumbent the system finds.
• With Automated Daily Hierarchy Adaptation, transfers made outside the position hierarchy are corrected on the next run. The threshold setting also applies.
• Everyone according to position hierarchy uses the Transfer Event Reason from Position Management Settings, unless ERD is enabled.

Job Relationships for Vacant Matrix Positions

When a leaver's position is referenced by other positions' matrix relationships, the setting Synchronize Job Relationships for Vacant Matrix Positions decides:

• No: the relationships pointing to the leaver are not updated. For mass positions, they move to another incumbent chosen at random.
• Delimit Job Relationships: the relationships are ended. For mass positions, another incumbent is used.
• To Incumbent On Next Higher Level Position: the relationships move to the next higher-level incumbent.

Deactivating the Position on Termination

With Show "Deactivate Position" Option in Employee Termination Screen = Yes, the termination screen can also deactivate the position. The field is visible and editable only if all of these hold:

• the employee has a position, and it is active
• the position has no other incumbents, now or in the future
• it has no active child positions, now or in the future
• it has no future right to return
• it is not referenced in other positions' matrix relationships in the future
• the user can edit the position's Effective Status (Correct or Insert, depending on the operation)
• it has no pending or active job requisitions (Recruiting integration)
• there are no pending workflows for the position or for Job Information referencing it

Workflows in Position Management

A position is both a foundation object (it exists without an incumbent) and a transaction object, so it gets many updates. SAP's leading practice is to protect positions with workflows for changes, creation or copying, and position-to-Job-Information synchronization. The rules that trigger them are in Section 13.3.

Position-Based Approvers

• Position Relationship approver type: the approver is the incumbent of the Position, Parent Position, or Parent Parent Position. Choose the Relationship to Approver:
  • Employee Position (the subject user's position)
  • Initiator Position (the initiator's position)
  • Position (the Position MDF object, for workflows on the position object)
• Never use Position as a Role. A position is an object instance with incumbents, not a user, so the system cannot resolve the role. Use Position Relationship instead.
• For position creation, use Context = Target and Relationship to Approver = Position. Otherwise creation workflows will not reach the approver.

Dynamic Roles Based on Position

A dynamic role based on position can be used only for MDF Position workflows and uses the changed position data to resolve the approver. For example, if a position moves from the US to Canada but is still used in a US dynamic role, US approvals keep going to that position's incumbent in Canada.

It needs the Base Object field on the dynamicRole element of the Corporate Data Model. Export it in Admin Center > Import/Export Corporate Data Model, point the DTD to corporate-datamodel.dtd, add this field to the dynamicRole element, validate, and import:

<hris-field max-length="128" id="baseObjectType" visibility="both">
  <label>Base Object</label>
</hris-field>

SAP notes that customers without Provisioning use the Admin Center import, which is the only customer-accessible way.

Approver Replacement Exception

Approver replacement (Section 9.1) does not apply to workflows for the Position MDF object.