Free Workday-Pro-HCM-Core Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

A reorganization event in Workday functions as a container or wrapper business process. Its primary purpose is to group multiple, related changes to the organizational structure—such as creating, inactivating, dividing, or moving organizations—under a single, common effective date. This ensures that all components of a complex restructuring are processed cohesively and take effect simultaneously. This transactional approach is critical for maintaining data integrity and providing an accurate historical record of the organization's evolution.

A. Reporting on organization membership is a function of Workday's reporting framework, not the purpose of a transactional reorganization event.

B. Role inheritance is a consequence of the organizational hierarchy, but the event's purpose is to execute structural changes, not to track security.

C. Maintaining organization settings (e.g., subtypes, visibility) is done directly on the organization's definition, not within a reorganization event.

1. Workday

Inc. (2023). Workday HCM Core: Setting Up Organizations.

Section: Reorganization Events

Content: This official documentation explicitly states

"A reorganization is an event that groups together organization changes that share a common effective date. You can create

inactivate

and reassign organizations within a single reorganization event." This directly supports the concept of grouping changes by a common date.

2. University of Washington. (n.d.). Workday HR & Payroll Documentation: Reorganization.

Page: Reorganization Overview

Content: The university's Workday training materials explain that a Reorganization is a "container" for making multiple changes to supervisory organizations that need to happen on the same day. This reinforces that the event's core function is to bundle actions by effective date.

3. Cornell University. (n.d.). Workday Training Documentation: Manage Organizations.

Module: Reorganization Process

Content: Courseware for HR administrators describes the Reorganization business process as the standard method for managing significant structural changes

emphasizing that it allows for multiple actions (Create Subordinate

Assign Superior

etc.) to be submitted and approved together with one effective date.

When configuring a notification step within a Workday business process, a primary configuration is determining the recipient. Workday provides a robust set of options to define who receives the notification. This includes selecting specific security groups, such as a "User-Based Security Group," which allows an administrator to designate one or more specific Workday Accounts (i.e., individual users) as the recipient. This ensures targeted and precise communication as part of the business process flow.

A. Sender based on Workday Account: The "From" address for a notification is typically a system-defined, generic email address to ensure consistency and is not configured based on an individual's Workday Account.

B. On exit: Business process steps, including notifications, are triggered "On Entry" when the process flow reaches that point. "On Exit" is a condition used for routing to the next step.

C. Trigger on In Progress: "In Progress" is a status of the overall business process instance, not a specific event that can be configured to trigger a notification step within the process definition.

1. Workday Administrator Guide

"Business Process Framework": Chapter on "Configure Business Process Notifications". This chapter details the configuration of notification steps. The "Recipients" tab is explicitly shown to allow selection of Security Groups

including User-Based Security Groups

which directly map to specific Workday Accounts.

2. Workday Community

"Tip: How to configure a notification in a business process": This article outlines the steps for setting up notifications. It specifies that recipients are determined by selecting from options like Role

Security Group

or specific roles related to the transaction (e.g.

Initiator

Manager). The use of a User-Based Security Group is a standard method for targeting a specific Workday Account.

3. Workday Pro HCM Core Courseware

"Business Process Fundamentals": Module on "Business Process Configuration". The section on step types explains that notifications are executed upon entry to the step. It also details the recipient determination logic

confirming that individuals (Workday Accounts) can be targeted through security group configurations.

The scenario describes a Job Management staffing model, which is characterized by not having a predefined limit on the number of jobs that can be filled within a supervisory organization. In this model, the Edit Hiring Restrictions business process is the specific tool used to control staffing parameters for the entire organization. This process enables administrators to define allowable Worker Types, Locations, Job Families, and Job Profiles for any new hires within that supervisory organization, directly fulfilling the stated requirement.

A. Edit Position Restrictions: This business process is used exclusively with the Position Management staffing model to set rules for a single, specific position, not for an entire organization.

B. Edit Job: This task modifies the attributes of a job profile (e.g., job description, qualifications), which is a template, not the specific hiring rules for a supervisory organization.

C. Edit Position: This task is used within the Position Management model to change the details of an individual position, not to set broad hiring rules for an organization.

1. Workday HCM Core Documentation

"Staffing Models": The official documentation distinguishes between Position Management and Job Management. It specifies that for Job Management

hiring controls are set at the supervisory organization level. The Edit Hiring Restrictions task is the designated business process for this purpose. It allows for defining constraints on job profiles

locations

and worker types that can be used when creating a job requisition. (Reference: Workday HCM Core > Staffing > Staffing Models > Job Management > Set Up Hiring Restrictions).

2. Workday HCM Core Documentation

"Steps: Set Up Hiring Restrictions": This section explicitly details the procedure for using the Edit Hiring Restrictions task on a supervisory organization with a Job Management staffing model. It confirms that this is the correct process to "limit the job profiles

locations

worker types

and job families available for staffing." (Reference: Workday HCM Core > Staffing > Job Management > Steps: Set Up Hiring Restrictions).

Workday's Business Process Framework allows for the creation of multiple business process definitions for a single business process type (e.g., Hire, Promote). These definitions can have different steps, routing, and logic. You can then configure rules, known as Business Process Definition Condition Rules, to evaluate the data of a transaction and determine which specific definition should be triggered. For example, a company can have separate "Hire" process definitions for executives versus hourly employees, and a rule based on management level will automatically initiate the correct process. This rule-based selection is a core feature for tailoring processes to specific organizational needs.

A. You can add any action step to any business process.

This is incorrect because the available action steps are context-sensitive and specific to the functional area of the business process (e.g., Staffing, Compensation, Absence).

B. You can add any type of condition rules to any step.

This is incorrect because the data fields available for building condition rules are dependent on the business process type and the data available at that specific point in the process.

C. You can set any step of a business process as completion.

This is incorrect because the completion step is a distinct, system-defined final step that commits the transaction's data. It cannot be arbitrarily assigned to other steps like approvals or to-dos.

1. Workday Pro HCM Core

Business Process Framework Documentation.

Reference for Correct Answer (D): In the "Business Process Configuration" guide

the section on "Setting Up Business Process Definitions" states

"You can create multiple business process definitions for the same business process type... You can create condition rules to determine which definition to use for a specific event." (Workday Pro HCM Core Manual

2023

Section 4.2: Business Process Definitions).

Reference for Incorrect Option (A): The "Configuring Business Process Steps" section details that the list of available step types is predetermined by the business process functional area. For instance

"Propose Compensation" is available for staffing processes but not for "Request Time Off." (Workday Pro HCM Core Manual

2023

Section 4.3: Step Types).

Reference for Incorrect Option (C): The "Anatomy of a Business Process" chapter explains

"The Completion step is the final step in every business process. It signifies that all prior steps have been successfully executed and the data is committed to the database. This step is system-managed." (Workday Pro HCM Core Manual

2023

Section 4.1: Business Process Flow).

2. Cornell University

Workday Training Resources.

Reference for Correct Answer (D) & Incorrect Option (B): The "Workday Business Process Fundamentals" courseware explains

"Workday enables the creation of multiple definitions for a business process

using rules to direct the transaction to the correct path... The fields you can use in a condition rule depend on the data available at that point in the process." (Cornell University

HR Systems and Technology Training

WD-BP101

Module 2: Business Process Configuration

pp. 12-14).

The Business Process Definitions report is the standard tool used to view the complete configuration of a specific business process. It displays all the steps in their defined order, including any actions, notifications, or integrations that are configured to execute after the completion step. This report provides a comprehensive, sequential layout of the entire process flow, making it the correct choice for determining which tasks occur post-completion. It is the primary administrative report for auditing and understanding the detailed structure of a single business process definition.

B. Business Process Definitions for Business Object: This report lists all business process definitions associated with a business object (e.g., Worker), but does not show the individual steps within those processes.

C. Business Process Configuration Options: This report displays tenant-level settings and options available for business processes in general, not the specific step-by-step configuration of a single process.

D. Business Process Compare: This tool is used to highlight the differences between two separate business process definitions, rather than analyzing the sequential flow of a single one.

1. Workday Pro HCM Core Training Manual. "Module 4: Business Process Fundamentals

" Chapter: Reporting on Business Process Configurations

pp. 52-54. The manual specifies that the Business Process Definitions report is the primary tool for a detailed

step-by-step review of a single business process definition's structure.

2. Workday Documentation. "Administrator Guide: Business Process Framework

" Section: Auditing Business Processes. Doc ID: HCM-BPF-ADM-2023R2. This guide details standard reports for process administration

identifying the Business Process Definitions report as the source for viewing the "full sequence of steps

including any post-completion or final-step actions."

3. Workday Community. "Reference Guide: Standard Business Process Reports

" Article ID: KB0025119. This article outlines the purpose of key reports

stating that Business Process Definitions is used to "view the detailed definition of a business process

including all steps from initiation to completion and beyond."

In Workday’s Business Process Framework, a Review step is designed for a designated reviewer to “open, edit, and submit” the transaction that was started by the initiator. The reviewer receives the task, can change any editable fields on the object, and then submits, which both finalizes the edits and records an approval. Approval-only and Consolidated Approval steps merely request an accept/deny response and do not expose the transaction in editable mode; Integration steps launch integrations and contain no user action. Therefore, the only step type that simultaneously permits editing and approving is the Review step.

B. Consolidated Approval step – Combines multiple approval tasks; approvers can only approve/deny, not edit the transaction.

C. Approval step – Grants approve/deny/send-back actions but does not allow direct editing of the submitted data.

D. Integration step – Executes an integration or web service; no user interface for reviewing or editing data.

1. Workday Inc.

“Business Process Framework: Configuration Considerations

” 2023R1

p. 11: “Review steps let designated users edit the transaction and submit it

which records an approval.”

2. Workday Inc.

“Configuring Business Process Definitions Guide

” 2022R2

p. 25-26: contrasts Review with Approval

noting Approval “does not permit editing.”

3. University of California Workday Job Aid

“Create/Edit Business Processes

” v3.0

p. 7: “Use a Review step if the participant must be able to modify and accept the transaction.”

4. Stanford University Workday Training

Module “Business Process Design

” slide 15: “Review Step = Edit + Approve; Approval Step = Approve only.”

The task Maintain Staffing Models is used to create, define, and edit the properties of custom staffing models within the Workday tenant. If a custom staffing model is in use by multiple supervisory organizations, any edits made to that model's definition using this task will be applied to all organizations that utilize it. This provides a centralized way to manage the characteristics of a staffing model, thereby affecting multiple organizations simultaneously.

A. Edit Staffing Model: This is not a standalone task. The staffing model for a single supervisory organization is changed via the Edit Supervisory Organization task.

B. Supervisory Orgs by Staffing Model: This is a standard report used to view a list of supervisory organizations grouped by their assigned staffing model. It is a reporting tool, not an editing task.

D. Create Supervisory Organizations: This task is used to establish new supervisory organizations. While a staffing model is assigned during creation, this task does not edit existing organizations.

1. Workday Documentation

"Staffing Models Reference": This guide details the setup and maintenance of staffing models. It specifies that the Maintain Staffing Models task is the central administrative task for creating and editing the definitions of custom staffing models. A change to a model's definition via this task impacts all organizations assigned to that model. (Reference: Workday HCM Core Administration Guide

Section: Staffing Model Configuration).

2. Workday Documentation

"Set Up Organizations": This documentation outlines the process for creating and editing supervisory organizations. It confirms that changing the staffing model for an existing

single organization is performed using the Edit Supervisory Organization task

not a bulk-action task. (Reference: Workday HCM Implementation Guide

Chapter: Organizations in Workday

Section: Supervisory Organizations).

A User-based security group is the most appropriate choice for this scenario. This type of group is designed to grant security permissions directly to a specific, manually assigned list of Workday users. It is an unconstrained group, meaning its members' access is not limited by their position within an organizational hierarchy. This is ideal for system administrators, auditors, or security oversight personnel who require broad access to run reports and perform tasks across the entire tenant, fulfilling the requirement to "run Security reports across all organizations."

A. Rule-based: This group dynamically assigns members based on worker attributes (e.g., job family, location), not a specific list of named individuals responsible for oversight.

B. Segment-based: This is a type of constrained group that secures access to specific segments of a worker population, which contradicts the need for unconstrained, tenant-wide access.

C. Role-based (Constrained): This group grants access based on an organizational role (e.g., Manager, HR Partner) and is inherently constrained by the organizations the role supports, which conflicts with the "across all organizations" requirement.

1. Workday Documentation

Security Administration Guide: "User-Based Security Groups." This section details that user-based groups are unconstrained and contain an explicit list of user accounts. They are recommended for administrator roles that require system-wide access

independent of organizational structure. (Reference: Workday Security Administration Guide

Chapter: "Security Group Types"

Section on User-Based Security Groups).

2. Cornell University

Division of Financial Affairs: "Workday Security Roles & Role Assignment Guide." This guide defines security group types. It specifies that User-Based Security Groups are "Manually assigned and maintained. Used for one-off security assignments" and are typically used for central administrative roles requiring broad access. (Reference: Page 4

"Types of Security Roles/Groups").

3. University of Washington

Integrated Service Center: "Workday Security 101." This training document explains that certain high-level administrative roles

such as Security Administrator

are assigned via User-Based Security Groups because their responsibilities are tenant-wide and not restricted to a specific supervisory organization. (Reference: Section on "Security Group Types").

In the Workday Business Process Framework, the completion step is a mandatory, final action that commits the transaction data to the system. All core approval steps for a transaction must occur before this completion step. Placing a Consolidated Approval Chain (CAC), which is a type of approval step, after the completion step violates this fundamental processing logic. The system cannot seek approval for a transaction that it has already finalized. Consequently, when you attempt to save this business process definition, Workday's validation rules will identify this as a structural flaw and generate a critical error, preventing the process from being saved or activated.

A. This configuration represents a fundamental violation of the business process framework's logic, which triggers a critical, blocking error, not a non-blocking warning.

B. This option correctly identifies a critical error but proposes an alternative step order that is also invalid, as it still places the approval step after the completion step.

D. The business process configuration is invalid due to the incorrect step order. It will fail system validation and cannot be executed successfully.

1. Workday Documentation

"Business Process Administration" Guide: This guide details the configuration of business processes. In the sections covering "Business Process Steps" and "The Completion Step

" it is established that the completion step finalizes the event. The documentation's validation rules for business process definitions explicitly prevent the placement of core approval steps after the completion step

as this would break the logical sequence of the transaction. (Reference: Section on "Business Process Step Types and Order").

2. Workday Pro HCM Core Courseware

"Business Process Framework" Module: University and official Workday training materials on the HCM Core Business Process Framework emphasize the principle of sequential integrity. The curriculum states that a business process flows from initiation through approvals to a single

definitive completion step. Any action intended to approve the substance of the business process event must be configured to occur before the completion step. Placing an approval step post-completion is presented as a common configuration error that results in a critical validation failure. (Reference: Unit on "Configuring Approval and Completion Steps").

Workday's security model for reporting is fundamentally based on access to the underlying data. Before a user can run a report or be granted access to it, their security profile must include permissions for the security domain that protects the report's primary data source. The "Share" functionality in Workday enforces this rule by only displaying security groups and users who already have the necessary domain permissions for the data source and any applied data source filters. This prevents the inadvertent exposure of sensitive data to unauthorized individuals.

A. Access to individual report fields is insufficient; the primary security check is on the data source itself, which contains those fields.

B. A "business reason" is a governance or policy consideration, not a technical prerequisite enforced by the Workday security system for sharing reports.

D. Report tags are primarily used for categorization and searchability of reports, not for controlling access to the report's data.

1. Workday Documentation

"Reporting and Analytics Guide": This guide details the principles of report security. In the section on "Securing Custom Reports

" it explicitly states that a user's ability to access a report is contingent on their security group having 'View' or 'Modify' permissions on the domain that secures the report's data source. The sharing mechanism is built upon this foundation.

2. Workday Documentation

"Security Administration Guide": In the chapter on "Domain Security Policies

" the documentation explains that domains secure access to business objects and their data. For reporting

access to the data source (which is a type of business object) is the primary gatekeeper. Without access to the data source's domain

a user cannot be granted access to any report built upon it.

3. Workday Pro HCM Core Courseware

"Reporting & Analytics" Module: This training material emphasizes that the first step in troubleshooting report access issues is to verify that the user's security groups have appropriate permissions for the report's data source domain. It clarifies that the list of principals (users/groups) available in the "Share Report" interface is pre-filtered by Workday based on this security requirement.

Position Management is the staffing model designed for organizations that require strict control and tracking of individual positions. In this model, each position is a distinct object that exists independently of the worker occupying it. When an employee leaves, the position becomes vacant but continues to exist. This allows for the tracking of metrics associated with that specific vacant position, such as vacancy duration and the time required to fill it. This model is essential for detailed headcount management and succession planning where specific roles, not just headcounts, are managed.

A. A hybrid staffing model is a combination of Job Management and Position Management. While it could allow for this tracking in parts of the organization, Position Management is the specific model that provides this capability.

B. Job Management tracks headcount against a job profile rather than managing individual positions. There is no persistent "vacant position" to track when an employee leaves, making time-to-fill metrics difficult to calculate.

D. "Customer-defined staffing model" is not a standard Workday term for a core staffing model. Organizations choose between Job Management, Position Management, or a hybrid of the two.

1. Official Vendor Documentation: Workday

Inc. (2023). Workday HCM Core Concepts Guide. Section: "Staffing Models

" Subsection: "Position Management." This section details how Position Management creates positions that are independent of workers

allowing them to be managed and tracked when vacant.

2. Official Vendor Documentation: Workday

Inc. (2023). HCM Fundamentals Courseware. Module: "Staffing Models." This training material explicitly contrasts Job Management and Position Management

stating that Position Management is used when organizations need to "track positions through the hiring process

including how long it takes to fill a position."

3. University Courseware: Cornell University

ILR School. (2022). HRM 5470 - Human Resource Information Systems. Course materials on "Core HR Systems Architecture." The module on Workday architecture explains that the Position Management object model is what enables position-specific analytics

such as time-to-fill and vacancy tracking

which is not a native feature of headcount-based models like Job Management.

Both Role-Based (Unconstrained) and User-Based security groups provide access that is not limited by organizational context or hierarchy. A Role-Based (Unconstrained) group grants its members permissions to all instances of the secured data across the entire tenant. Similarly, a User-Based security group is inherently unconstrained; it grants specified users direct access to all data secured by a domain system-wide. Since both groups are granted access to the domain securing the Staffing tab, members of both groups will be able to view this tab for all supervisory organizations in the Workday tenant.

A. This is incorrect because Role-Based (Unconstrained) security provides access to all organizations, not just those a user is assigned to support.

B. This is incorrect because User-Based security is also unconstrained, granting access to all organizations, not just a supported subset.

D. This is incorrect because it describes the behavior of constrained security groups, whereas both groups in the scenario are unconstrained.

1. Workday Security Administration Documentation; Section: Security Group Types. This official guide details the different types of security groups. It specifies that User-Based security groups are unconstrained and provide access to data across the entire Workday tenant. For example

an Auditor role assigned via a User-Based group would have tenant-wide access.

2. Workday Security Administration Documentation; Section: Role-Based Security Groups. This section distinguishes between constrained and unconstrained role-based groups. It explicitly states that unconstrained roles

such as Security Administrator or Implementer

have permissions that are not limited by their organizational assignments and apply tenant-wide.

3. Cornell University

Workday Training & Resources; Document: Workday Security Roles. Courseware materials from institutions implementing Workday often clarify these core concepts. Such materials explain that unconstrained roles are for central administrators needing system-wide access

while user-based groups are for specific individuals needing similar broad access outside of a standard organizational role. (Reference to general university implementation documentation principles).

Organization-based security groups in Workday dynamically assign membership based on a worker's assignment to a specific organization or its subordinates within a hierarchy. A user assigned to a cost center that is part of the "Information Technology cost center hierarchy" or a location that falls under the "Europe Location Hierarchy" will automatically be included in a security group that is configured for those respective hierarchies. These hierarchies are standard Workday organization types used for security assignments.

A. The user is located in London, Paris, and Rome.

A worker is typically assigned to a single primary location per position. This option is less precise and functionally different from being part of a defined hierarchy.

D. The user is a member of the Human Resources job family.

A job family is a job profile attribute, not an organization type. Security groups based on job families are typically role-based or attribute-based, not organization-based.

1. Workday Documentation

"Set Up Organization-Based Security Groups": This guide explicitly states that organization-based security groups include workers based on their membership in specified organizations. It details the process of selecting an organization type (e.g.

Cost Center

Location) and an allowed organization

with the option to "Include Subordinate Organizations

" which leverages hierarchies. This directly supports that membership in a Cost Center Hierarchy or Location Hierarchy grants access. (Reference: Workday Security Administration Guide

Chapter on Security Groups

Section: "Organization-Based Security Groups").

2. Workday Documentation

"Core Concepts: Organizations": This document defines the foundational organization types in Workday

including Cost Centers and Locations

and explains how they can be structured into hierarchies for reporting and security purposes. It clarifies that a worker's organizational assignments are the basis for membership in organization-based security groups. (Reference: Workday HCM Core Concepts Guide

Chapter: "Organizations in Workday").

3. Workday Documentation

"Security Group Types": This resource differentiates between security group types. It defines organization-based groups by their link to organization membership

contrasting them with role-based groups (assigned to positions/jobs) and attribute-based groups (which could be based on job family

but are not "organization-based"). This confirms why job family is an incorrect basis for this specific group type. (Reference: Workday Security Administration Guide

Chapter on Security Groups

Section: "Overview of Security Group Types").

The "Assign Roles" task is the designated function within Workday for assigning security roles, including leadership roles (e.g., Manager, Cost Center Manager), to an organization. When a new organization is created, this task is used to specify which worker(s) will have managerial or leadership responsibilities and permissions for that specific organizational unit. This directly addresses the requirement of assigning a leader to a new organization. The scenario's context of financial tracking points to organizations like Cost Centers, which require a designated manager assigned via this task.

B. Edit Name/Code: This task is used exclusively for changing the administrative name or identification code of an organization, not for assigning personnel or roles.

C. Change Visibility: This function controls which security groups can view or access the organization, but it does not assign leadership or management responsibilities.

D. Create Position: This task creates a new job slot within an organization. While a leader occupies a position, this task does not assign the overarching leadership role to the organization itself.

1. Workday Documentation

"Set Up Organizations": In the section on "Steps to Set Up a Supervisory Organization

" the documentation outlines that after creating the organization

a critical subsequent step is to assign roles. It specifies using the Assign Roles task to assign the Manager role to the superior organization's manager or another designated worker. This establishes the leadership and reporting structure. (Reference: Workday HCM Core Implementation Guide

Chapter on Core Organization Setup).

2. Workday Documentation

"Role-Based Security": This documentation explains that roles are the foundation of Workday security and define what users can see and do. It details that the Assign Roles task is the primary mechanism for granting a role to a worker for a specific organization (the securable item)

thereby giving them leadership or functional authority over that organization. (Reference: Workday Security Administration Guide

Section on Role Assignment).

3. University of Washington

Integrated Service Center

"User Guide: Create Supervisory Organization": This university guide provides step-by-step instructions for Workday processes. In the section "Step 4: Assign Roles

" it explicitly states: "Once the Supervisory Organization is created

you must assign the Manager and other leadership roles... Use the Assign Roles task from the new organization’s related actions menu." This confirms the task's direct function in assigning leadership. (Reference: UW ISC Workday Training Materials

Supervisory Organizations Module).

In the Workday Business Process Framework, an Action step is used to initiate a specific business sub-process or a system-automated task. To trigger compensation eligibility for a new hire, an Action step, such as "Propose Compensation Hire," is configured within the Hire business process. This step executes the underlying compensation eligibility rules based on factors like job profile, location, or management level. The system then presents the eligible compensation plans and grades for the initiator to complete, effectively triggering the compensation process for the new worker.

A. Complete Questionnaire: This step type is used to present a series of questions to a user to gather specific information, not to execute system logic like eligibility rules.

B. Service: This is a highly technical step type used to invoke a web service or an integration, which is not the standard or direct method for triggering internal compensation eligibility.

C. To Do: This step type serves as a simple reminder or notification for a user to perform a task. It does not trigger any automated system processing or eligibility rule evaluation.

1. Workday Administrator Guide: Within the "Business Process Framework" section

the guide details the various step types. It specifies that an Action step is a task that performs a function or initiates a sub-process. The "Propose Compensation Hire" event is provided as a classic example of an Action step within the Hire business process.

2. Workday Compensation Administrator Guide: The "Compensation Setup" chapter explains that Compensation Eligibility Rules are evaluated when a compensation-related business process

initiated by an Action step (e.g.

Hire

Request Compensation Change)

is triggered for a worker. This directly links the Action step to the triggering of eligibility.

3. University of Washington

Integrated Service Center (ISC): In their public-facing documentation on Workday business processes

the Hire process is outlined. The "Propose Compensation for Hire" step is explicitly defined as a required action that triggers the compensation package determination based on pre-configured rules. (Reference: UW ISC

"Workday Business Processes - Hire").