6.1 Event Operations: Rescind, Cancel, Correct & Mass Operations

6.1 Event Operations: Rescind, Cancel, Correct & Mass Operations

Quick Answer: In Workday, business process events transition through defined lifecycle states. When operational errors occur or circumstances change, administrators must select the exact corrective action: Cancel aborts an In Progress event before it finishes, purging pending tasks from My Tasks Inboxes; Rescind reverses a Successfully Completed event, unwinding all committed data and cascading through dependent downstream transactions; Correct edits specific data fields on a Successfully Completed event without undoing the event itself or breaking subsequent history; and Reassign Task transfers a pending, in-flight action step from one user's Inbox to another eligible worker. Both Rescind and Correct carry stringent security permissions due to their substantial audit and data integrity ramifications.

---

The Business Process Event Lifecycle

Every transactional workflow executed within the Workday Business Process Framework generates an Event record. The event serves as the central audit object tracking who initiated the process, the exact parameters submitted, every intermediate approval or review, and the final resolution.

                                  +-----------------------+
                                  |       Initiated       |
                                  +-----------------------+
                                              |
                                              v
                                  +-----------------------+
        +------------------------>|      In Progress      |<------------------------+
        |                         +-----------------------+                         |
        |                                     |                                     |
  [Reassign Task]                             |                                     |
(Transfers pending step                       |                                     |
 to another user)                 +-----------+-----------+                         |
        |                         |                       |                         |
        |                         v                       v                         |
        |                 +---------------+       +---------------+                 |
        |                 |   Canceled    |       | Successfully  |                 |
        |                 | (Terminates   |       |   Completed   |                 |
        |                 |  in-flight BP)|       +---------------+                 |
        |                 +---------------+               |                         |
        |                                                 |                         |
        |                                 +---------------+---------------+         |
        |                                 |                               |         |
        |                                 v                               v         |
        |                         +---------------+               +---------------+ |
        +-------------------------|   Corrected   |               |   Rescinded   |-+
                                  | (Edits fields;|               | (Unwinds data;| (If dependent
                                  |  keeps event) |               |  cascades back|  events exist)
                                  +---------------+               +---------------+

Primary Event Lifecycle States

1. Initiated: The event has been drafted and submitted into the workflow engine.
2. In Progress: The event is actively traversing the defined step sequence, awaiting action, approval, review, or integration execution.
3. Successfully Completed: All required steps, approvals, and sub-processes have finished. All state changes (e.g., compensation increases, organization transfers, title changes) have been committed to the in-memory database.
4. Canceled: An In Progress event was intentionally terminated prior to completion. Uncommitted changes are discarded.
5. Rescinded: A previously completed event was formally reversed. Committed data changes are rolled back, and the system restores the pre-event state.

---

The Cancel Operation: Halting In-Flight Events

The Cancel operation is used when a business transaction that is currently moving through an approval workflow is no longer needed, was submitted in error, or must be aborted before taking effect.

Architectural Mechanics of Cancel

• Pre-Condition: The event must be In Progress. An administrator or user cannot cancel an event that has already achieved Successfully Completed status.
• Task Purging: When an event is canceled, Workday immediately deletes or clears all associated pending tasks, approvals, and To-Dos from the My Tasks Inboxes of all assigned workers and security groups.
• Database Impact: Any draft data entered during initiation or subsequent action steps is permanently discarded. No changes are committed to the worker's operational profile or organizational structures.
• Event History Retention: Workday does not erase the event record from the database. The event status changes to Canceled. The complete audit trail—including who initiated it, who approved earlier steps, who initiated the cancel action, the exact timestamp, and the mandatory Cancel Reason—is permanently preserved in the tenant.

Cancel vs. Deny / Send Back

It is vital to distinguish Cancel from other workflow termination or redirection actions:

• Deny (Reject): Executed by an approver on an individual approval step. Depending on process configuration, Denying a step terminates the process event with a status of Denied.
• Send Back: Executed by an approver to return the event to a prior step or to the initiator to correct specific information. The event remains In Progress.
• Cancel: Executed from the Related Actions menu of the event itself by the initiator, an HR Partner, or a Business Process Administrator to abandon the entire transaction.

Security Governance for Cancel

Permission to cancel an in-flight business process is governed directly by the Business Process Security Policy (BPSP) for that specific business process type. Within the BPSP, administrators configure security groups under the "Who Can Cancel" section. Typically, this permission is granted to the initiator of the event, the HR Partner for the worker's organization, and Central HR Administrators.

---

The Rescind Operation: Reversing Completed Events

The Rescind operation represents one of the most powerful and high-risk administrative capabilities in Workday HCM. It is used when an event has Successfully Completed, but business circumstances dictate that the transaction must be entirely undone.

Architectural Mechanics of Rescind

• Pre-Condition: The event must have a status of Successfully Completed.
• State Rollback: Rescinding an event unwinds every change committed by that event. For example, rescinding a Change Job event restores the worker's previous position, job profile, compensation package, supervisory organization, and management hierarchy to their exact pre-event values.
• Audit Preservation: Like Cancel, Rescind never deletes the event from the database. The event record remains permanently with a status of Rescinded. Workday records the user who performed the rescind, the entry moment, and the mandatory Rescind Reason.
• Downstream Financial & Operational Risk: Rescinding completed staffing or compensation transactions can lead to severe discrepancies in external payroll systems, tax reporting, benefits eligibility, and regulatory filings if data has already been transmitted downstream.

Cascading Dependencies & The Reverse Unwind Chain

Workday enforces strict referential integrity. When an administrator attempts to rescind an event, Workday's dependency engine evaluates whether subsequent events rely on the data committed by that event.

Consider the following real-world sequence of events for a worker:

Timeline of Worker Events:
1. Jan 10: Hire Employee (Successfully Completed)
2. Feb 15: Request Compensation Change (Successfully Completed)
3. Mar 20: Change Job / Transfer (Successfully Completed)
4. Apr 05: Request One-Time Payment (In Progress)

If an administrator attempts to directly rescind the Hire Employee event on May 1st:

1. Dependency Block: Workday will block the rescind operation with a hard validation error. Because the worker has subsequent completed events (Compensation Change, Transfer), the system cannot delete the baseline worker instance while dependent transactions exist.
2. The Unwind Sequence: To successfully rescind the Hire event, the administrator must unwind transactions in strict reverse chronological order:
   • First, Cancel the pending April 5th Request One-Time Payment event.
   • Second, Rescind the March 20th Change Job event.
   • Third, Rescind the February 15th Request Compensation Change event.
   • Finally, Rescind the January 10th Hire Employee event.

Exam Watchpoint: Rescinding a Hire event returns the employee to a Pre-Hire status. The pre-hire record remains in the tenant and can be hired again, converted, or deleted. Rescinding a Hire does NOT delete the Pre-Hire record.

Rescind vs. Terminate

A frequent point of confusion on certification exams is the difference between Rescind and Terminate:

• Rescind Hire: Treats the individual as if they never worked for the organization. It invalidates employment history, zeroes out continuous service, and cancels all historical standing.
• Terminate Employee: Acknowledges that the worker did work for the company, but their employment relationship has ended. It preserves historical tenure, job history, compensation records, and tax filings, setting the worker to Terminated status with an effective separation date.

---

The Correct Operation: Surgical Field-Level Modification

The Correct operation allows administrators to modify specific data values recorded during a Successfully Completed business process event without unwinding the transaction or disrupting dependent history.

When to Use Correct

Correct is designed for fixing data entry mistakes, typographical errors, incorrect reason codes, or minor date misalignments that occurred during the original transaction. For instance, if an HR Specialist completed a Promotion event but mistakenly selected "Annual Merit" as the reason code instead of "Promotion - Career Progression", or misspelled the worker's business title, Correct enables an in-place adjustment.

Field-Level Restrictions & Immutability Rules

Workday restricts which fields can be corrected based on downstream dependencies and data constraints:

• Allowable Corrections: Business titles, event reason codes, comments, and certain position attributes can typically be corrected directly.
• Restricted Corrections: Fields that alter fundamental eligibility or data boundaries (such as changing an Effective Date across a boundary where another completed event already exists) may be blocked by validation rules.
• Audit Trail of Corrections: When an event is corrected, Workday retains the original field value, the new field value, the identity of the user who made the correction, and the entry moment in the event's audit history.

Correct vs. New Business Process Event

Administrators must never use Correct to record genuine real-world changes that happened after the event. If an employee receives a salary increase three months after being hired, the administrator must initiate a Request Compensation Change business process, NOT use Correct on the original Hire event.

---

Reassign Task: In-Flight Workflow Remediation

During operational execution, workflow steps frequently become stuck. An approver may be on emergency leave without having configured delegation, a manager may have departed the company, or a security reassignment may have left an approval step orphaned.

Architectural Mechanics of Reassign Task

• Target: Applies strictly to pending actionable steps (Approvals, Reviews, To-Dos) within an In Progress event.
• Action: An authorized administrator executes the Reassign Task related action on the event or uses the Reassign Tasks report.
• Routing Shift: The task is immediately removed from the original assignee's My Tasks Inbox and deposited into the target user's Inbox.
• Preservation of Process Definition: Reassigning a task does not alter the underlying Business Process Definition. It is a single-instance operational override.
• Audit Compliance: The business process history explicitly documents the reassignment: "Reassigned from [Original User] to [New User] by [Administrator Name] on [Timestamp]" along with the required reason text.

Reassign Task vs. Delegation

---

Managing Events at Scale: Mass Operations

Everything above describes acting on one event. Real tenants routinely need the same operation applied to hundreds of events at once — a merit cycle loaded against the wrong effective date, a reorganization that stranded 400 approvals on a manager who has left, an EIB that created 1,200 job changes with a bad cost center. Clicking Related Actions on each event is not a viable answer, and the certification exam tests whether you know the administrative alternative.

The Mass Operation Management Task

Mass Operation Management is the central administrative task for acting on many in-flight or completed business process instances in a single run. The administrator selects a mass operation type, filters the population of events, reviews the selection, and submits. Available operation types include:

A separate dedicated task, Mass Rescind Business Process, reverses completed events in bulk — the batch counterpart to a single Rescind, with the same cascading unwind of downstream transactions described earlier in this section.

Mass Operations Do Not Bypass Security

This is the point the exam presses hardest. A mass operation is not an administrative override. Each targeted event still evaluates the business process security policy, so to mass rescind you must hold the rescind permission in the Who Can Do Actions on Entire Business Process section of that policy; to mass cancel you need cancel; to mass advance you need the manual-advance permission. An administrator with Mass Operation Management access but no rescind permission on the Hire business process simply gets an empty result set for Hire events.

Operational Discipline

• Filter before you submit. Mass operations are irreversible at the batch level — there is no single "undo this mass run" action. Reversing a bad mass rescind means re-entering every event.
• Test in Sandbox first. Run the same filter in Sandbox and confirm the selected population size matches expectations before touching Production.
• Watch for cascades. Mass rescind inherits the reverse unwind chain, so rescinding 500 hires also reverses their downstream compensation, benefit, and payroll input events.

---

Event Operations Comparison Matrix

---

Certification Pitfalls & Common Exam Traps

1. The Mass Operation Override Trap: A scenario gives an administrator access to Mass Operation Management and asks why a mass rescind returned no Hire events. Candidates answer that mass operations bypass security. They do not — every event still evaluates the business process security policy, and the administrator lacks rescind permission on that business process.
2. Mass Advance Availability Trap: Advance Business Process is offered as the fix for a stuck To-Do or a step assigned to a named individual. Mass advance is available only for steps that can be assigned to a security group.
3. The "Cancel a Completed Event" Trap: Exam questions often describe a manager who wants to cancel a promotion that completed yesterday. The prompt will offer "Cancel the event" as an option. Cancel is impossible on a completed event; the only valid operation to reverse it is Rescind.
4. The "Rescind Deletes Data" Trap: Questions frequently test whether rescinding an event deletes the event record from the database. Workday never purges event records during a rescind; it transitions the status to Rescinded and maintains an immutable audit trail.
5. Rescinding Hires with Dependent Events: An exam scenario may ask what happens when an administrator attempts to rescind a hire for an employee who has an approved compensation change and an approved transfer. The action will fail with a dependency error until the compensation change and transfer are rescinded first in reverse chronological order.
6. Rescind vs. Terminate for Erroneous Hires: If a candidate never showed up on their first day (no-show), the correct action is Rescind Hire, NOT Terminate. Terminating creates an official employment and separation record, whereas Rescind accurately reflects that employment never commenced.