13.1 Position Management Rule Scenarios and Rules for Position Data Entry
Key Takeaways
- Most Position Management rule scenarios are registered in Position Management Settings before they take effect.
- Propagation from Job Classification to Position uses Rules for MDF Based Objects (base object Position, purpose Evaluate), assigned to the jobCode field.
- Default values for new positions come from a rule under Initialize Rules on the Position object, or from the field's Default Value for simple data types.
- The Define Copy-Relevant Position Fields rule works for Create Lower-Level and Create Same-Level Position, but not for Copy Position.
- Parent Position must never be included in the copy rule, because the system derives it from the hierarchy.
13.1 Position Management Rule Scenarios and Rules for Position Data Entry
Quick Answer: Position Management uses application-specific rule scenarios (sync, copy-relevant fields, mass change, right to return, Recruiting, and Fieldglass), most of which are registered in Position Management Settings. It also uses general Rules for MDF Based Objects with Position as the base object for propagation, defaults, code generation, workflows, and alerts. Three rules automate data entry: Job Classification → Position propagation, defaults on creation, and Default Position Attributes for new lower-level or same-level positions.
How Rules Work in Position Management
Business rules add logic: if this data changes in a certain way, the system reacts in this way. They are not delivered out of the box, because requirements vary. As a reminder, a rule has IF conditions (or Always True), THEN statements, optional ELSE IF and ELSE (catch-all) branches, an assignment, and an event. For example, a propagation rule assigned to the Position object's jobCode field fires onChange, before the position is saved.
Position Management Rule Scenarios
| Scenario | Purpose | Where it is registered |
|---|---|---|
| Synchronize Position Changes to Incumbents | Sync position changes to incumbents' Job Information. Also trigger it when the position field changes in Job Information. | PM Settings > Synchronization > Rule for Synchronizing Position to Job Information |
| Synchronize Incumbent's Changes to Position | Sync Job Information changes back to the position | PM Settings > Synchronization > Rule for Synchronizing Job Information to Position |
| Define Copy-Relevant Position Fields | Default values for new lower-level or same-level positions and the Create Same-Level Position (Copy Rule) Quick Action | PM Settings > UI Customizing > Rule for Defining Copy-Relevant Position Fields |
| Update Rule for Mass Change Run | Select and update positions in a Mass Change Run | The Mass Change Run request in Manage Mass Changes for Metadata Objects |
| Unassigned Incumbent from Position for Right to Return | Whether to unassign the incumbent | PM Settings > Right to Return > Unassign from Position |
| Create Right to Return for Incumbent | Whether to create a right to return | PM Settings > Right to Return > Create Right to Return |
| Derive Job Requisition Template in Recruiting Integration | Which requisition template to use | PM Settings > Integration > Rule for Deriving Job Requisition Template ID |
| Map Fields from Position to Job Requisition in Recruiting Integration | Field mapping to the requisition | PM Settings > Integration > Field Mapping Rule to Create Job Requisition from Position |
| Map Fields from Position to External Job Requisition in Fieldglass Integration | Field mapping to a Fieldglass requisition | PM Settings (Fieldglass mapping rule) |
Rules for MDF Based Objects with Position
The general Metadata Framework scenario, with Position as the base object, is used to:
- generate position codes automatically from a sequence (Section 13.3)
- set default values when a new position is created
- trigger workflows when positions are created or changed (Section 13.3)
- configure MDF alerts and notifications
Rule 1: Propagate Job Classification Data to the Position
When the Job Code changes, related fields such as job level and pay grade fill in from the job classification. This works during creation and change.
- Configure Business Rules > + > Metadata Framework > Rules for MDF Based Objects.
- Name and ID: Propagate_Job_Classification_to_Position. Start date 01/01/1900. Base Object: Position. Purpose: Evaluate.
- Build the IF/THEN, for example setting the position's job title, job level, and pay grade from the selected job classification.
- Assign it with the rule's assignment icon (This rule can be assigned at the field level for object "Position"), or in Configure Object Definitions > Position > Take Action > Make Correction. Open jobCode > Details > Rules and select the rule.
- Test in Manage Positions > Create New > Position: pick a job code and watch the fields fill in. Cancel without saving.
Because the rule sits on a field, it fires onChange: when the job code changes from null or from another value.
Rule 2: Default Values When a Position Is Created
For fields common to many positions that do not come from the job classification, such as FTE, To Be Hired, Mass Position, Position Controlled, and Change Reason, a rule can set defaults:
- Create a Rules for MDF Based Objects rule with IF Always True, and set the values in THEN.
- Assign it in the Position object's Rules section under Initialize Rules, and save.
New positions then open with the defaults, for example a common legal entity, standard hours, or incentive plan. Alternative: the field's Default Value in the object definition. It works only for String, Number, Date, and Boolean fields. THR79's practice system defaults new positions to To Be Hired with FTE 1 this way.
Rule 3: Default Position Attributes (Copy-Relevant Fields)
When users Create Lower-Level or Create Same-Level Position from the Position Org Chart, this rule copies chosen values from the source position into the new position. It also works for Create Same-Level Position (Copy Rule) from My Team Positions and from Joule.
- It does not work for Copy Position, which copies all fields.
- Never include Parent Position in this rule. The system derives it from the hierarchy.
- Create Same-Level Position (Copy All Fields) ignores the rule and copies everything.
Example: open Default_Position_Attributes, choose Insert New Record effective today, and add THEN expressions: Set New Position.Pay Grade = Source Position.Pay Grade and Set New Position.Incentive Plan = Source Position.Incentive Plan. Register the rule under PM Settings > UI Customizing.
Test: in the Position Org Chart, open Sales Director, NE (DIR_SALESNE) and choose Create Same-Level Position. Enter DIR_SALESEU, Sales Director, Europe, To Be Hired, 38 hours, Ace Germany, and Frankfurt. The rule fills in the rest before saving, and the parent position is assigned automatically.
How is the rule that propagates Job Classification data into a position configured and assigned?
Which statement about the Default Position Attributes (copy-relevant fields) rule is correct?
A company wants every new position to default to To Be Hired = Yes and FTE = 1 without writing a rule. What does THR79 offer?