Workforce rules, the right one at the right time
Four rules do almost all the work, and they are not interchangeable: one pushes entity defaults, one pushes component definitions, one processes loads, one recalculates. The doc says exactly when each runs, and this page holds that answer with the traps attached.
Note: Workforce, the people-planning part of Planning, Oracle's budgeting and forecasting module, ships a set of prebuilt rules whose names all start with OWP_. Running the wrong one, or none, is the most common Workforce support ticket. This page is which rule, when, and the traps.
The whole module is mapped on the Planning index.
◆ The dictionary, four rules, when each runs, from the doc.
| Rule (24.12 set, legacy name in brackets) | Run it when, per Oracle's when-to-run page |
|---|---|
| Synchronize Defaults 2.0 | Entity defaults changed: a benefit, tax, or additional earning added to or removed from entity defaults. From a form row it targets one employee-job; from white space it prompts for scope. |
| Synchronize Definition 2.0 [Synchronize Component Definition] | An existing component changed: rate table, payment frequency, salary grade, maximum value. Pushes the updated definition to employees and jobs. The doc states plainly that it does not update entity defaults; the two rules are not interchangeable. |
| Process Loaded Data with Synchronize Defaults | After importing compensation data: copies from the current period to future periods in the year range and applies entity defaults. The trap, stated in the doc: it sets Headcount to 1 and Partial Payment Factor to 100% for every employee unless you loaded different values. Load those columns or accept the defaults knowingly. |
| Calculate Compensation 2.0 | Data changed on a form and expenses need recalculating for that employee or job. |
Verbatim from the doc: beginning with the 24.12 update, Workforce uses these rules for all new applications. Older applications keep working, and Oracle recommends rewiring action menus to the 2.0 rules. If you customized the prebuilt rules or their Groovy templates, updates that rewrite them for performance require re-applying your changes by hand afterward.
◆ The cautions, Master FTE, the scheduling route, and performance.
| Field-tested cautions | |
|---|---|
| Master FTE interplay | With Split-Funded FTE enabled, the Master FTE value is mandatory per employee, per the enablement doc. The same doc adds two rule interactions: a changed Master FTE calls for Synchronize Definition, and changed tax tiers are recalculated only by the Synchronize rules, never by Calculate Compensation. |
| Scheduling route | Community boards carry reports of prebuilt Workforce rules failing when launched through EPM Automate while succeeding in Calc Manager. Before wiring the nightly schedule, run the exact scheduled command once by hand in your own pod and read the job log. |
| Performance | Run rules for a parent entity in multiple instances, one per child branch, rather than one pass across every entity. This is Oracle's own recommendation on the same page, and it is the difference between minutes and hours at 4,880 heads. |
The problem: Workforce numbers change overnight and nobody is sure which rule or which load did it.
What we build: The employee-job rows export nightly with the job logs landed beside them.
What you get: Every changed number traces to the rule and the load that changed it, and silent defaults surface the morning they happen.
- Defaults against Definition
- Entity defaults against component definitions. Different rules.
- the load trap
- Headcount 1, payment factor 100%, unless loaded. Doc-stated.
- Master FTE
- Mandatory with Split-Funded FTE. Changes call for Synchronize Definition.
- by branch
- Parallel instances per child branch. Oracle's own advice.