6.2 Effective Dates vs Entry Moments & Subprocess Execution

6.2 Effective Dates vs Entry Moments & Subprocess Execution

Quick Answer: Workday's data architecture is fundamentally bitemporal, managing two parallel timelines for every transaction: the Effective Date (the functional date when an employment, organizational, or compensation change takes effect in the real world) and the Entry Moment (the immutable system timestamp recording down to the millisecond when the transaction was committed). Backdating a transaction creates a past-dated (retroactive) event, which triggers automatic recalculation engines across payroll, absence accrual balances, and benefits. Conversely, future-dated events complete their workflow routing upon approval but remain dormant until their arrival date. In complex workflows, parent business processes trigger subprocesses (e.g., Hire invoking Propose Compensation Change); critically, each subprocess executes under its own independent Business Process Definition and Security Policy, inheriting neither approvals nor security from the parent.

---

The Bitemporal Data Architecture: Effective Date vs. Entry Moment

Traditional enterprise databases record transactions along a single timeline, making it difficult to answer historical audit questions. Workday solves this by employing a bitemporal data model that tracks two independent temporal axes for every business object.

                                   THE BITEMPORAL TIMELINE

     Effective Date Axis (Functional Reality)
     --------------------------------------------------------------------------------->
          Jan 01                    Apr 01                     Jul 01
      (Effective Date)           (Effective Date)           (Effective Date)
     Original Base Pay          Retroactive Increase       Scheduled Promotion
          $85,000                    $95,000                    $110,000
            ^
            |  (Transaction entered on May 15 with retro date of Apr 01)
            | 
     --------------------------------------------------------------------------------->
          Jan 01                     May 15                    Jun 02
      (Entry Moment)             (Entry Moment)             (Entry Moment)
     Entered in System          Committed to Memory        Approved Future Event

     Entry Moment Axis (System Audit Record)

1. Effective Date (Functional Time)

• Definition: The date on which an organizational change, staffing event, or compensation adjustment takes functional effect in the enterprise.
• Business Application: Governs which compensation grade, supervisory hierarchy, job profile, management level, and benefits eligibility package apply to the worker on any given calendar day.
• Mutability: Configured by the user during event initiation (subject to business process security policy controls and validation rules).

2. Entry Moment (Transaction Time)

• Definition: The exact system-generated timestamp (UTC date, hour, minute, second, and fraction of a second) when an event was committed to the in-memory database.
• Business Application: Provides an immutable audit trail proving exactly what the system knew at any specific moment in history.
• Immutability: Completely read-only and generated by the Workday kernel. No user, administrator, or integration can modify or forge an Entry Moment.

Point-in-Time Querying: As-Of-Date vs. As-Of-Entry-Moment

Workday Report Writer leverages this bitemporal model through two reporting parameters:

• As-Of-Date: Evaluates the organization as it was functionally configured on that calendar day, regardless of when the data was keyed in.
• As-Of-Entry-Moment: Reconstructs the exact state of the database at a historical system timestamp. This answers critical legal and forensic questions, such as: "What did our executive headcount report show on June 1st at 5:00 PM, before the retroactive July reorganizations were keyed in on June 10th?"

Temporal Model Comparison Matrix

---

Past-Dated (Retroactive) Events & System Recalculations

A past-dated (retroactive) event occurs when an event is submitted with an Effective Date prior to the current system date (e.g., submitting a promotion on May 15th with an effective date of April 1st).

Recalculation Cascades

When a retroactive event completes, Workday automatically inserts the transaction into the worker's historical timeline and dynamically triggers recalculation engines:

1. Retroactive Payroll Processing (Retro Pay):

   • If Workday Payroll is deployed, the system detects differences between the wages already disbursed and the newly effective compensation rates.
   • Workday calculates retro earnings, tax recalculations, and deduction true-ups, queuing retroactive adjustments into the worker's next active payroll period.

2. Absence Accrual Recalculations:

   • If a retroactive job change alters a worker's FTE, standard weekly hours, or continuous service length, Workday recalculates absence accrual ledgers back to the effective date.
   • Historical time-off balances are re-tabulated, adjusting current available balances.

3. Benefits Eligibility Re-evaluation:

   • A retroactive transition from part-time to full-time status triggers a retroactive benefits life event.
   • The system evaluates plan eligibility rules back to the retro date, prompting retroactive premium adjustments and enrollment opportunities.

Retroactive Collisions & Out-of-Order Processing

When multiple transactions occur on the same worker across overlapping time horizons, Workday evaluates effective sequence. If an administrator inserts a retroactive compensation change between two already-completed compensation changes, Workday re-evaluates the entire chronological chain forward to ensure that subsequent compensation packages correctly inherit or override the retroactive values.

---

Future-Dated Events & Queuing Mechanics

A future-dated event occurs when an event is submitted with an Effective Date after the current system date (e.g., initiating a new hire on September 1st with a start date of October 15th).

Lifecycle of a Future-Dated Event

1. Workflow Completion: The event routes through its configured step definitions, approvals, and reviews immediately. Once the final approval is granted, the event achieves Successfully Completed status.
2. Dormant State: Although the event is completed, the data changes remain dormant. On the worker's active profile, the current supervisory organization, title, and pay rate remain unchanged.
3. Midnight Activation: At 00:00:00 on the morning of the Effective Date (evaluated in the tenant's primary or worker's local timezone), the Workday kernel activates the event, and the worker's operational profile updates automatically.

Handling Intervening Events (Future Event Queuing)

What happens if an employee has an approved future-dated transfer scheduled for November 1st, and their manager submits an off-cycle compensation increase effective October 1st?

• Workday permits the intermediate event to proceed.
• When the October 1st compensation event completes, Workday automatically evaluates whether the November 1st future event contains conflicting position or compensation data.
• If a conflict arises (e.g., the future transfer proposed a salary that assumed the old base pay), Workday displays a Future Dated Event Warning, prompting the initiator or HR Partner to review and reconcile the future event.

Reporting on Future-Dated Events

Standard operational reports (e.g., Headcount, Worker Directory) evaluate workers as of the current date (Today) by default. Future-dated hires and transfers are excluded unless the report definition or user explicitly selects an As-Of-Date on or after the future effective date, or activates the "Include Future-Dated Events" prompt.

---

Subprocesses: Parent-Child Architecture

In complex enterprise business processes, a single overarching lifecycle event requires multiple specialized, cross-functional data inputs. Rather than cramming all tasks into a monolithic workflow, Workday uses a Parent-Child Subprocess Architecture.

+---------------------------------------------------------------------------------------+
|                               PARENT BUSINESS PROCESS: HIRE                           |
|  Step a: Action - Initiate Hire                                                       |
|  Step b: Approval - Manager Approval                                                  |
|  Step c: Subprocess - Propose Compensation Change ---------------------------------+  |
|  Step d: Subprocess - Edit Government IDs -------------------------------------+    |  |
|  Step e: Subprocess - Assign Pay Group ------------------------------------+   |    |  |
|  Step f: Action - Complete Onboarding                                      |   |    |  |
+----------------------------------------------------------------------------|---|----|-+
                                                                             |   |    |  
    +------------------------------------------------------------------------+   |    |  
    |                                                                            |    |  
    v                                                                            v    |  
+------------------------------------+  +------------------------------------+        |  
|      SUBPROCESS: ASSIGN PAY GROUP  |  |     SUBPROCESS: EDIT GOVT IDS      |        |  
| - Uses own BP Definition           |  | - Uses own BP Definition           |        |  
| - Governed by own Security Policy  |  | - Governed by own Security Policy  |        |  
| - Routes to Payroll Partner        |  | - Routes to HR Operations          |        |  
+------------------------------------+  +------------------------------------+        |  
                                                                                      |  
    +---------------------------------------------------------------------------------+  
    |                                                                                    
    v                                                                                    
+---------------------------------------------------------------------------------------+
|                      SUBPROCESS: PROPOSE COMPENSATION CHANGE                          |
| - Uses own BP Definition                                                              |
| - Independent Approvals: Comp Partner -> VP Approval                                  |
| - Governed by Compensation Security Policy (Independent of Hire Security)            |
+---------------------------------------------------------------------------------------+

What is a Subprocess?

A Subprocess is a discrete, autonomous business process definition that is invoked dynamically as an intermediate step within a parent business process. Canonical examples include:

• Hire (Parent): Invokes Propose Compensation Change, Edit Government IDs, Assign Pay Group, Add Academic Appointment.
• Change Job (Parent): Invokes Propose Compensation Change, Change Organization Assignments, Edit Position Restrictions.
• Terminate (Parent): Invokes Manage Union Membership, Close Position, Severance Calculation.

Synchronous vs. Asynchronous Subprocess Execution

• Synchronous Subprocesses: The parent business process pauses at the subprocess step and cannot advance to subsequent steps until the subprocess has completed all of its internal actions and approvals.
• Asynchronous Subprocesses: The parent process launches the subprocess and immediately continues down its own step chain without waiting for the child process to finish. This is typically used for non-blocking downstream tasks, such as triggering an IT account provisioning notification.

---

Subprocess Routing & Security Independence

A cornerstone concept on the Workday HCM certification exam is the complete structural and security independence of subprocesses.

Independent Business Process Definitions

When Hire invokes Propose Compensation Change, the compensation step does not follow the step rules of the Hire process. It executes the distinct Propose Compensation Change Business Process Definition configured in the tenant:

• If the stand-alone Propose Compensation Change definition contains an approval step assigned to the Compensation Partner, that exact approval step triggers during the Hire workflow.
• Condition rules configured on the subprocess definition evaluate independently based on the compensation data submitted.

Independent Security Policies (No Security Inheritance)

A widespread misconception is that the initiator or approvers of a parent process automatically inherit rights to view or approve its subprocesses. Workday strictly prohibits security inheritance:

• The permissions to view, initiate, and approve the parent Hire process are governed by the Business Process Security Policy: Hire.
• The permissions to view, edit, and approve the compensation subprocess are governed by the Business Process Security Policy: Propose Compensation Change and the underlying Compensation Domain Security Policies.
• If a Manager initiates a Hire and has security to approve the hiring step, but lacks security permissions in the Propose Compensation Change security policy, the Manager cannot view or approve the compensation step. The compensation task routes exclusively to authorized compensation security groups.

Subprocess Execution Matrix

---

Certification Pitfalls & Common Exam Traps

1. The Subprocess Security Inheritance Fallacy: An exam item will ask: "An HR Assistant initiates a Hire. The Hire business process definition includes a Propose Compensation Change subprocess step. Why does the HR Assistant receive an access error when attempting to open the compensation step?" The trap answer suggests the process definition is corrupt. The correct answer is that security is not inherited: the HR Assistant lacks permissions in the Propose Compensation Change Business Process Security Policy or relevant compensation domain.
2. Confusing Effective Date with Entry Moment in Audits: When asked how an auditor can determine what an employee's salary was documented as on March 1st before a retroactive increase was keyed in on March 15th, the solution requires filtering by Entry Moment (Entry Moment <= March 14), not Effective Date.
3. Future-Dated Invisibility: If an administrator creates a report on current active workers and cannot find a newly hired director whose hire process finished yesterday, the issue is that the hire has a future Effective Date. The director will not appear on "as-of-today" reports until their start date arrives.
4. Asynchronous vs. Synchronous Blocking: If a parent process fails to advance to Step 5, it is frequently because Step 4 is a synchronous subprocess that is still waiting for an approval within its own internal workflow.