Hire Business Process Guidelines

Administrator Guide

Overview

The Hire business process (BP) is a foundational workflow in Workday Human Capital Management (HCM) that orchestrates the sequence of tasks, approvals, and system actions you need to bring a new employee into the organization. It controls the:

What (steps and subprocesses)

Who (security groups responsible for each step)

When (the order of operations) for a hiring event

A properly configured Hire business process ensures data accuracy, involves the correct stakeholders at the appropriate times, and automates tasks like account creation and notifications.

Each Hire process is an instance of a business process definition. It serves as a central hub that connects recruiting, compensation, benefits, and core (human resources) HR data, ensuring a seamless transition from candidate to employee. While Workday provides a default definition, most organizations create multiple, rule-based definitions tailored to different populations (by country, worker type, or supervisory organization).

These are the sections in this topic:

Subprocesses

Consolidated Template

Prerequisites

Process Initiators

Limitations

Common Business Process Workflows

Common Business Process Workflows for Consolidated Approvals

Subprocesses

The Hire business process can include several subprocesses to handle specific tasks.

Propose Compensation Hire: This subprocess determines the new hire's salary and other compensation components.

Create Workday Account: This generates the new hire's Workday account, giving them access to the system.

Onboarding: You can trigger this process after the hire is complete to manage new hire tasks such as:

Completing tax forms.

Reviewing documents.

Enrolling in benefits.

Background Check: This process is applicable only if the new hire isn't from Recruiting and you want to check the background status in Workday.

Consolidated Template

A Consolidated Template in a Workday business process is a configuration that combines the data entry screens of multiple, distinct subprocesses (such as salary, bonus, and stock) into a single, unified user interface. Use the template as an option when the business process has multiple, related initial setup items for a single role at the beginning of the process and add it as the Initiation step to simplify the initiator's job.

These sub business processes are available for consolidation. To ensure these sub business processes appear in the consolidated template, ensure users have View
and Modify
access to the relevant domains:

Edit Government IDs

Service Date Changes

Change Organization Assignments for Worker

Assign Employee Collective Agreement

Assign Pay Group

Payment Election Enrollment Event

Compensation related sub business processes

Prerequisites

You must meet these prerequisites in the target supervisory organization before you can initiate a Hire transaction:

Security: Configure the business process security policy to grant specific security groups permission to these action steps:

Initiating Actions: Determine who can start the Hire process. Typical security groups include Recruiter, HR Administrator, and HR Partner.

Review and Approval Steps: Determine who can approve the hire transaction. Typical security groups include Manager, HR Partner, and Compensation Partner.

View All: Determine who can view the in-progress or completed hire transaction. Typical security groups include HR Administrator, HR Auditor, and Implementers. Grant View All permission to the roles that can initiate the business process to ensure all validations run correctly

To view a list of applicable security domains, access the Domain Security Policies for Functional Area report and select the Staffing, Core Compensation, and Organization and Roles functional areas.

Staffing Model: The supervisory organization must have a staffing model assigned:

Position Management: An open, available, and approved position must exist in the supervisory organization. You initiate the Hire action against this specific position.

Job Management: You can optionally configure hiring restrictions on the supervisory organization. If not configured, you define the job details when hiring the worker into the Job Management organization. See Concept: Staffing Models.

Job Profiles: Create the necessary job profiles with details such as:

Job description

Management level

Compensation Grade

Pay Rate Type

Other qualifications

Pre-Hire Tracking: If you track candidates before they are formally hired, configure pre-hire statuses, evaluation methods, and recruiting sources.

Edit the Hire Business Process: Define the steps, conditions, and notifications for the Hire business process. This includes configuring service steps like Create Workday Account.

Configure Optional Fields: Determine which optional fields in the Hire business process to hide, make view-only, or require for specific security groups.

Process Initiators

You trigger the Hire business process when a person with the appropriate security permissions initiates one of the Hire Employee tasks. Workday provides several variations of this task, enabling you to select the one that best fits your process.

Example: Some task versions provide enhanced search capabilities to prevent creating duplicate records by searching for existing pre-hires, former workers, or students. See

You can initiate the process from:

The search bar by typing Hire Employee.

The related actions menu of a Job Requisition.

The related actions menu of a Supervisory Organization.

The related actions menu of an unfilled Position.

The Ready for Hire status from the Offer or Employment Agreement Business Process. See Concept: Hire Employee Initiating Actions.

Limitations

Corrections and Integrations: Event-driven integrations that you configure to trigger from the Hire process only re-trigger for corrections you make to the top-level Hire event. Corrections you make only within a subprocess, won't re-trigger the integration. Example: Correcting compensation in Propose Compensation Hire after the main hire is complete,

Configuration Complexity: The high degree of configurability means the initial setup can be complex and requires a thorough understanding of the hiring processes in your organization.

Send Back Option: You can send a business process back to the Initiation or Review step for corrections using the Send Back action. This action is accessible during the review or approval stages of the business process definition, provided the process isn't complete.

Onboarding Distinction: Distinguish between the Hire process and Onboarding. The Hire process focuses on getting the employee into the system, while Onboarding is about the new hire experience and completing post-hire tasks.

Autocomplete Functionality: Autocomplete doesn't support send-backs in the business process workflow. Service steps always run, but Workday skips any notifications associated with those service steps. See Setup Considerations: Autocomplete Staffing Events.

Corrections to completed Hire events: These don't automatically re-trigger associated events, such as benefits enrollments. Depending on the specific changes made, you might need to manually initiate certain subprocesses to ensure the worker record updates accurately.

Correct Worker Start Date: You can't use this business process for contingent workers, and you can't rescind it once submitted.

Common Business Process Workflows

These are the common workflow configuration paths for the Hire
business process, with the steps listed in their typical order.

To view the diagram of a business process workflow, click

View Diagram

on the

View Business Process Definition

page when you're editing the business process definition.

Path 1: Standard Workflow Configuration

This is the most common configuration, representing a straightforward, linear process for a typical employee hire without complex pre-hire requirements.

A: Initiation

B: Action (Propose Compensation for Hire)

C: Action (Request One-Time Payment)

D: Service (Create Workday Account)

E: Action(Assign Pay Group)

F: Action (Complete Onboarding Tasks)

G: Completion (Hire Completion Step)

Path 2: Hire with Background Check Subprocess Configuration

This path integrates a formal background check as a required, gating step in the process. The hire cannot proceed until the background check is successfully completed, ensuring compliance with hiring policies.

A: Initiation

B: Action (Enter Personal Information)

C: Action (Background Check)

D: Action (Propose Compensation for Hire)

E: Action (Assign Pay Group)

F: Approval (Review Hire and BGC Results)

G: Completion (Hire Completion Step)

Path 3: Hire with Integrated Onboarding Workflow Configuration

This configuration path connects the Hire process to other critical onboarding subprocesses, creating a seamless end-to-end onboarding experience for the new hire and internal teams.

A: Initiation

B: Action (Propose Compensation for Hire)

C: Action (Request One-Time Payment)

D: Service (Onboarding Plan Assignment)

E: Action (Onboarding Setup)

F: Service (Create Workday Account)

G: Action (Assign Pay Group)

H: Action (Onboarding)

Path 4: Hire with Union or Collective Agreement Configuration

This path is for organizations where new hires must be assigned to a collective agreement, which can influence their compensation, benefits, and other job details.

A: Initiation

B: Action (Propose Compensation for Hire)

C: Action (Assign Collective Agreement)

D: Action (Assign Pay Group)

E: Approval (Union Steward Review)

F: Approval (Manager Review)

G: Completion (Hire Completion Step)

Path 5: Autocomplete

This path streamlines your hiring process and reduces manual data entry for high-volume, standardized hiring processes where minimal manual intervention is required. Example: seasonal workers, retail staff.

Hire BP

Edit Definition

Enable Autocomplete

Enabling autocomplete bypasses certain steps in the business process, including approvals, to-do items, and review steps. If your process relies on these steps, consider the implications before using this workflow.

The success of Autocomplete depends on the accuracy and completeness of the data entered during the recruiting process. If required fields for the Hire event aren't populated from Recruiting or through Staffing Field Defaults, the process will not autocomplete. It will revert to the standard manual workflow.

Common Business Process Workflows for Consolidated Approvals

These are common workflow configuration paths for consolidated approvals, with the steps listed in their typical order.

Determine which security groups can review and approve consolidated steps. Configure the Hire business process security policy to grant these security groups permission to these consolidated steps. Typical security groups include Payroll security group.

Path1: Combined Approval for a Single Reviewer

This is the most frequent use case. It consolidates multiple subprocesses into a single task for an approver, such as an HR Partner or the hiring manager. This ensures the reviewer has a holistic view of the hiring event.

A: Initiation

B: Action (Propose Compensation for Hire)

C: Action (Change Organization Assignments)

D: Action (Request One-Time Payment)

E: Consolidated Approval (Approve the Hire, Propose Compensation, and Change Organization Assignments Events)

F: Completion (Hire Completion Step)

Path 2: Hierarchical Approval Using a Consolidated Chain

When multiple levels of management need to approve the hire and its associated details, a Consolidated Approval Chain is the leading practice. This combines the benefits of a consolidated approval with an approval chain. The Consolidated Approval Chain step is assigned to a role-based security group like Manager. The approval task is routed as a single item up the initiator's management hierarchy.

A: Initiation

B: Action (Propose Compensation for Hire)

C: Consolidated Approval Chain (Approve the Hire and Propose Compensation events)

D: Completion (Hire Completion Step).

Workflow Steps

These are the common step types used to build the business process workflow:

Initiation: Step Order
: Always the first step in any business process (labeled 'A').
Group
: Recruiters, HR Partners, or HR Administrators, or as part of Recruiting (Offer or Employment Agreement) or Integration, also by a Recruiter. Its setup is managed in the Hire Business Process Security Policy.
Specify
: Not applicable. This step launches the process.
Step Type Guidelines
:
Best practice: Use the Hire Employee task with enhanced search capabilities to avoid creating duplicate records. Train users on how to search for existing pre-hires or former workers before creating a new record.
Use case: This step begins the Hire workflow. The initiator enters the core information required to identify the pre-hire and the position they will fill, such as their name, the job requisition, and the planned hire date.
Example: A recruiter needs to hire a candidate for an open position. They use the "Hire Employee" task and search for the candidate name. They find that the candidate was a former intern and has a pre-hire record in the system. The recruiter selects the existing record to initiate the hire process, which pre-populates some of the candidate information.
Condition Rule Guidelines
: A condition rule in the initiation step serves as a validation mechanism to ensure the completeness of information that the initiator provides:
Best Practices: Keep initiation security straightforward. Use role-based security to grant initiation rights to the appropriate users.
Example: To only allow users based in the US to initiate the standard Hire process, add this rule on the security policy: User's Location is 'USA'.

Action: Step Order
: Place anywhere after the Initiation step and either before or after the completion step.
Group
: Any role that needs to enter or review data as part of the workflow, such as a Compensation Partner, HR Partner, Payroll Administrator, or the Employee as Self.
Specify
: Specify the subprocess that the step will trigger such as Propose Compensation Hire, Change Personal Information.
Step Type Guidelines
:
Use Case: One of the most common step types used to call another business process (a subprocess) to gather specific or additional information from the new hire.
Example: An action step labeled Complete New Hire Questionnaire is routed to the new hire inbox.
Condition Rule Guidelines
:
Best practice: Use condition rules to streamline the process and ensure users only see relevant tasks. This avoids confusion and unnecessary work.
Use case: To dynamically run steps based on data.
Example: Trigger a Request One-Time Payment action step only if a sign-on bonus is being offered.
For more information, see Concept: Action Step.

Approval: Step Order
: You can typically place it after all major data entry steps are complete and before the final completion step.
Group
: A role with the authority to approve the transaction, such as a Hiring Manager, Management Level +1 (the manager's manager), or an HR Manager.
Specify
: You can configure an approval chain, which routes the transaction up a management hierarchy until a certain level is reached.
Step Type Guidelines
: This step acts as a formal gate to validate a transaction. The approver can approve, send back (to a prior step for correction), or deny the hire. This ensures oversight and compliance with company policies.
Best Practices:
Place an Approval step after all major data entry steps are complete but before the final completion step of the business process.
Configure Advanced Routing to prevent approvers from approving their own transactions. Set the routing restriction to Exclude Event Subject and the Alternate Routing Security Group to Manager Relative to Excluded User.
Workday skips Approval steps when the initiator is the approver. Use a Consolidated Approval step to require approval.
When a business process is a subprocess within a larger process, consolidate the approval on the parent business process. This prevents the need for separate approval steps on each subprocess.
Use Case: Getting a manager to sign-off on a new hire compensation package.
Example: After the HR Manager proposes a compensation package, the business process routes an approval task to the department head for their review and sign-off.
Condition Rule Guidelines
:
Best Practices:
Avoid creating overly long or complex approval chains, as this can slow down the hiring process. Use condition rules to bypass approvals for standard, non-exception hires.
Use the standard condition rule No Current Assignee was Initiator or Prior Approver for most approval steps. This prevents the same user from having to approve a transaction they have already initiated or approved.
Use Case: To require additional approvals for exceptions.
Example: On an approval step for a Finance Partner, you can add this condition rule: Hire is for a Finance Department AND Proposed Annual Salary > 150,000 USD.
For more information, see Concept: Approval Step.

Autocomplete: Best practices:
While autocomplete is designed to skip many steps, there might be certain actions you always want to occur. Use
Route Normally
to specify which steps should execute even when the rest of the process autocompletes. Integrations and service steps always route normally.
Ensure that all required fields for a successful hire are correctly mapped and auto-populated from Recruiting into the Hire event. Leverage
Staffing Field Defaults
to pre-populate data where possible.
Example:
Hire Reason
is a required field for job changes. To ensure this field is always populated, configure the Offer business process to require it.
You can also enable autocomplete on various subprocesses of the Hire event, such as Assign Pay Group, Propose Compensation Hire, and Request One-Time Payment.
If you are using a consolidated Change Job template for internal hires, you must configure autocomplete for all subprocesses within that template for the parent process to do so.
To apply autocomplete selectively, use rule-based business process definitions. Then you can specify the conditions under which autocomplete should trigger.
Example: Create a rule that enables Autocomplete for retail positions but not for executive-level hires that require more manual oversight and approvals.
Since moving a candidate to the
Ready for Hire
status instantly triggers the Autocomplete process, you might need to adjust your recruiting workflow. Consider moving candidates to Ready for Hire closer to their actual start date to maintain flexibility.
Ensure that the security groups responsible for moving candidates to Ready for Hire status (Recruiter or Primary Recruiter) have the necessary permissions to initiate and complete the Hire event. This involves configuring the business process security policy for the Hire process and the dynamic completion steps in the Job Application business process.
For more information, see Concept: Autocomplete Business Processes.

Completion: This step signifies that the main workflow is finished. Once the completion step is executed, the hire is considered fully approved, and subsequent steps, such as, integrations, archiving, or notifications can run without holding up the core process.
Review the steps and identify which one should represent the final, required action for the hire to be considered approved. This is often the final approval step in the sequence. Locate the row for this step in the grid, and from the related actions menu of that step, select
Business Process
Set to Completion
.
A business process can only have one completion step. If another step is already marked as the completion step, Workday will automatically uncheck it and apply the designation to the step you have just selected.

Best Practices:
All Approval and Review Action steps must be placed before the Completion step.
Steps that require the worker to have a fully created record, such as adding talent data (photo, education, job history), are often placed after the Completion step.
The Create Workday Account service step can be placed after the Completion step.
An approval step, such as a Consolidated Approval Chain, is often set as the Completion step. This ensures that managers can approve all hire and compensation details in a single task before the hire is finalized in the system

For more information, see Concept: Completion Steps.

Consolidated Approval: You can add a Consolidated Approval step in place of a standard Approval or Approval Chain step within the business process definition.
This step type combines multiple preceding action steps within a business process into one inbox item for the approver. For example, in a Hire business process, instead of a manager receiving separate approvals for the new hire's job details, organization assignments, and compensation, a Consolidated Approval step can bundle all of these into a single, unified task. The approver can then review and approve all the details from one screen.

Consolidated Approval Chain: You can add a consolidated Approval Chain step in place of a standard Approval or Approval Chain step within the business process definition.
This step combines the functionality of a Consolidated Approval with an Approval Chain. It not only groups multiple approval items into a single task but also routes that task up a management or organizational hierarchy until it reaches the top or an exit condition is met.

Consider adding these steps for:
Homogeneous Tasks: Consolidation is most effective when the items being grouped are similar in nature, allowing the approver to apply a consistent review process to all of them.
Skipped Approvals: In some cases, a standard Approval step may be automatically skipped if the approver is the same person who initiated the transaction. Using a Consolidated Approval step can serve as a workaround to ensure the approval task is still generated and routed as intended.
Reducing Notifications: By bundling multiple approval requests into a single task, you significantly reduce the number of notifications sent to approvers, preventing "inbox fatigue" and helping them focus on the tasks that require their attention.
Clearly Define Step Conditions: Use condition rules to ensure that the consolidated step only triggers when appropriate. For example, you might configure a rule to use a consolidated approval only when the number of transactions exceeds a certain threshold.
Test Thoroughly: Before deploying a business process with a consolidated approval step, test it thoroughly to ensure it routes as expected and that the user experience for approvers is clear and intuitive. Confirm that approvers can easily navigate the consolidated view and approve or deny items as needed.
Example: Combine the approval for a new hire's job details and their compensation into a single task so that they can review and approve both the job information and the compensation package together.
Add a Consolidated Approval step after the Propose Compensation step and configure it to include both the Hire and Propose Compensation events.

Service: Step Order
: You can place it anywhere, but critical services like Create Workday Account are usually placed after the final approval and just before or on the completion step.
Group
: The system (Workday). In Workday, this "system" is a specific, configurable security principle called the Business Process Execution User.
Specify
: You select from a list of delivered Workday background processes.
Step Type Guidelines
:
Best practices:
Used to execute an automated, system-level action without manual intervention. The most common use case in the Hire business process is the Create Workday Account service, which generates the new user account and allows them to sign in to Workday.
You can’t create custom Service step types. Select from the list of services delivered by Workday.
You can’t change an existing step type, such as from Action to Service. Delete the step and add a new step with the correct type.
Condition Rule Guidelines
:
Best Practices: Understand the function of each service before adding it to a business process. Place service steps logically such as create the Workday account before assigning user-based security roles.
Use Case: To control when a system action occurs such as prevent the Create Workday Account service from running until the hire date is near.
Example: On the Create Workday Account service step, add this rule: (Hire Date minus Today's Date) is less than or equal to 7. This ensures the account isn't created more than a week before the start date.
For more information, see Concept: Service Step.

To Do: Step Order
: You can add in any order in the business process.
Group
: Any role. Often assigned to the Employee as Self, Hiring Manager, or support teams like IT Support or Facilities.
Specify
: You can enter instructions (using rich text and hyperlinks)
Step Type Guidelines
:
Best practices:
Use To Do steps to assign simple tasks or reminders that doesn't involve data entry These steps act as checklist items for tasks that occur outside Workday or where a dedicated business process step doesn’t exist. See Create Checklists.
Write clear, actionable instructions. If the task requires navigating to a specific page, include the navigation path in the To Do description.
Condition Rule Guidelines
:
Best Practices: Write clear, actionable instructions. Use due dates to help users prioritize tasks. Group related To Do's together in the process flow.
Use Case: To assign tasks conditionally.
Example: On a To Do for the Hiring Manager to Request a Corporate Credit Card, you can add this condition rule: Job Level is Director or higher.
For more information, see Concept: To Do Step.

Integration

The integration setup primarily utilizes Workday's Event-Driven Integration for Third-Party Payroll. It sends hire information to your third-party payroll vendor instantly when the Hire business process is complete, rather than waiting for a scheduled primary integration run. You enable this service on your primary Payroll Effective Change Interface (PECI) connector. It configures steps on the Hire business process to automatically send worker events from Workday to your third-party payroll vendor. The vendor validates the data and returns any errors for immediate correction.

Step Order

: Integrations can occur at multiple steps within the workflow. This step usually occurs after all approvals are complete, but before the process completes.

Group

: Performed by the system and requires you to assign a pre-configured Integration System User (ISU) that has the necessary security permissions to run the integration.

Specify

: Select the specific integration system to run. This could be a pre-built Workday connector, like one for a corporate card provider, or a custom-built integration using Workday Studio, Enterprise Interface Builder (EIB), or Core Connectors.

Step Type Guidelines

Use cases: Meet government regulations that require same-day reporting for new hires. Provide immediate payroll processing information for new employees, ensuring they are set up correctly in the third-party payroll system without delay. Allow the third-party payroll vendor to validate information and return any errors to you for immediate correction, reducing payroll errors.

Best practices: Ensure you have built and tested the two required endpoints (one for delivery, one for retrieval) with your payroll vendor before implementation. Test the integration thoroughly in a sandbox environment. Assign the review step to a security group that is actively monitoring tasks and can resolve any potential integration errors promptly.

Example: To add the steps to a Hire business process definition:

Access the Hire business process definition and select

Business Process

Edit Definition

Ensure you have an Assign Pay Group step that it is marked as a completion step.

Add a row with these details: Order: c, Type: Service, Specify: Transmit Employee Data to Third Party Payroll

Add another row with these details: Order: d, Type: Action, Specify: Review Event Driven Integration for Third Party Payroll, Group: Payroll Administrator

Select

to save the changes.

Condition Rule Guidelines

Best practices: Avoid configuring business process steps with audited entry conditions. This can create scenarios where the event-driven integration doesn't run as expected. To control execution, use the specific report field designed for this purpose.

Use Case: A common use case for a condition rule is to prevent the integration from running for hires with a future effective date. This can be useful if your downstream system can't handle future-dated transactions.

Example: To skip future-dated hires, create a condition rule on the Transmit Employee Data to Third Party Payroll step. Use the report field

Is Event Driven Integration Transaction Future Effective

in the rule's condition. Configure the step to run only when the value of this field is "No".

For more information, seeCreate Integration (Step).

Routing Modifiers

Use a routing modifier when a business process step needs to be directed to a specific security group, where workers have multiple positions or transactions that involve a change in assignment.

Routing modifiers are added to specific steps within a business process definition. The availability of a routing modifier depends on the business process and the step type:

The Line Level modifier can be applied to Approval and Consolidated Approval steps in business processes that support line-level routing, provided at least one security group on the step is an Intersection security group.

Common routing modifiers include:

Line Level: Used for approval steps on transactions with multiple lines, such as a supplier invoice. It routes for approval based on the context of each individual line to the relevant Intersection security group.

Best Practices

Ensure you provide security access to the these domains in the System functional area:

Business Process Administration

Manage: Business Process Definitions

Approval Chain: When organization-based routing is enabled on an Approval Chain step for a worker with multiple positions, Workday routes the step to all managers for the organization. Configure a routing modifier on this step to prevent this.

Reassignment Behavior: Workday disregards the routing modifier when a business process step is reassigned. The reassigned task will follow the standard routing for the new assignee.

Set Up Routing Restrictions (if needed): You can define routing restrictions to exclude certain individuals from the workflow. Use alternate routings to identify different security groups if necessary.

Save Changes: After configuring the routing modifiers and any additional settings, save your changes to apply the new routing rules.

Use with Intersection Security Groups for Line-Level Routing: When using the Line Level routing modifier, ensure that the step is assigned to at least one Intersection security group to allow Workday to route the lines to the correct approvers based on the intersection of their roles.

Verify Business Process Support: Routing modifiers are not available for all business processes so make sure to verify that the desired modifier is available for the specific business process you are configuring. You can check this in the business process definition.

Examples of processes supporting Primary Position and Additional Positions modifiers include: Contact Change, Edit ID Information, Start Performance Review, and Start Development Plan.

Examples of processes supporting Current and Proposed modifiers include: Change Job, Add Additional Job, and Offer.

Use Cases

You should consider adding a routing modifier to a business process step in these scenarios:

Line-Level Approvals: For transactions that can contain multiple lines with different contexts, such as a supplier invoice with lines for different cost centers, the Line Level routing modifier can be used on Approval or Consolidated Approval steps. This routes each line to the appropriate approver based on the context of that specific line.

Notifications

System Notifications

System notifications are default alerts generated by Workday for business process events. You can view all system notifications on the

Notifications

tab of the business process. You can disable a specific notification, though it’s often better to manage notification preferences at the user level or use custom notifications for more targeted alerts. See Configure Business Process System Notifications.

Global notification settings are managed in the

Edit Tenant Setup - Notifications

task.

Custom Notifications

You can create custom notifications that can initiate on any step of the business process to alert users about events, required actions, or status changes. To create a notification, navigate to the respective step in your business process definition and from the related actions menu of that step, select

Business Process

Add Notification

. See Create Custom Notifications.

Guidelines and Best Practices: Inform the hiring manager once the hire process is successfully completed.
Create a custom notification that is triggered upon the completion of the Hire business process. Personalize the email with the new hire name, start date, and manager name.
Notify the IT department about a new hire so they can prepare the necessary hardware and software.

Use Cases: Manager Notification on Hire Completion
Sending a welcome email to the new hire
IT Department Notification for Equipment Provisioning

Examples: Configure a custom notification to trigger on the completion step of the Hire BP, sent to the Hiring Manager security group. The message can include the new hire name, Employee ID, start date, and position.
Configure a notification with the subject "Welcome to the Team, [New Hire Name]!". The body of the email includes details about their first day, a link to the company new hire portal, and contact information for their manager.
Configure a custom notification on the Hire BP, sent to a specific security group for the IT team. The notification triggers on the entry of a specific step and includes details like the new hire name, location, and job title.

Issues and Solutions

This section lists common issues along with their corresponding causes and solutions.

Issue	Cause and Solution
Unassigned Tasks on Hire Business Process	Cause: The process includes unassigned tasks for which the specified security group doesn't contain users, or contains users only with disabled Workday accounts. Examples: A step is secured by the "Employee as Self" security group but the assigned user has a future hire date. The assigned user's Workday account is disabled, expired, or locked or the user doesn't have a Workday account to see their notifications or complete their assigned steps. Solution: Access the Unassigned Tasks report that displays the steps where this problem occurs. Add the "Pre Employee as Self" security group and test.
Review or Approval Doesn’t Work When Using a Consolidated Template	Cause: A consolidated review or approval step is not configured as step b in the Hire business process definition. Solution: Edit the Hire BP definition and move the main review/approval step such as Review Employee Hire to be order b. This ensures a seamless flow from initiation to the consolidated review page.
Custom Notification on Subprocess Triggers Incorrectly A notification on Propose Compensation Hire triggers when the parent Hire event is corrected, even if compensation was not changed.	Cause: The system detects a correction on the parent event and triggers notifications on all subprocesses. It cannot determine if a change was made specifically within that subprocess. Solution: This is working as designed. Be aware of this behavior. If this is problematic, consider moving the notification to the parent Hire process and triggering it based on a condition related to the subprocess data.
Cannot Add Validation to Hire Initiation Step An error message is needed if a required field like National ID is not entered on the initial Hire screen.	Cause: The initiation step might be creating a new pre-hire record, so the fields to be validated do not exist in the system until after the step is submitted. Solution: Don't attempt to put validation on the initiation step. Instead, add an Action step immediately after initiation assigned back to the initiator. Example: Change Personal Information or a Review step. Apply the validation rules to this second step.
Duplicate Employee Records	Cause: A new employee record is created for a person who already exists in the system as a pre-hire, former worker, or contingent worker. Solution: Use the versions of the Hire Employee task that include an enhanced search for existing persons. Train users to always search for an individual before creating a new pre-hire record. Regularly run audits to identify and merge duplicate records.
Incorrect Data Entered	Cause: Users enter incorrect information during the hire process, such as a wrong start date or an incorrect spelling of the name. Solution: Use data validation rules where possible to catch errors. For critical errors, you might need to use the Correct action on the completed Hire event to fix the data. Provide clear instructions and training to users on how to enter data correctly.
Process Stalled	Cause: The business process is stuck on a step because the assigned user is out of office or is not taking action. Solution: Configure delegation for key roles so that tasks can be automatically rerouted when a user is unavailable. Use the Business Process Status report to monitor the progress of hire events and identify any bottlenecks. You can reassign tasks to another user if necessary.
Incorrect Approvals	Cause: The business process is routing for approval to the wrong person or is not requiring approval when it should. Solution: Review the business process definition and the condition rules on the approval steps. Ensure that the security groups assigned to the approval steps are correctly configured and that the condition rules are accurately evaluating the data.
Error: This business process could not be completed because the proposed organization, position, headcount restriction, or job requisition selected is no longer available to be filled	Cause: The position associated with the Hire event has label "Available for Hire" marked as No. Solution: The position must meet all these conditions to be available: Create Position business process is complete Availability Date is on or before the current date Earliest Hire Date is on or before the effective date of the Hire business process Position restriction isn't filled and doesn't have an in-progress or completed Freeze Position business process Supervisory organization isn't frozen Position restriction doesn't have an in-progress merit promotion Position restriction isn't proposed in an in-progress staffing event Position restriction doesn't have a future-dated Move Worker (By Organization) or Move Worker (Supervisory) business process Position restriction doesn't have any in-progress or completed Close Position business processes Position restriction doesn't have an in-progress Job Requisition business process
Steps in a business process are not being entered during the event	Cause: The business process is enabled for autocomplete. Example: Edit Additional Data steps that are part of the Hire BP do not show in the Hire event process record because the Hire bp is enabled for autocomplete. When a business process is configured for autocomplete, Workday skips some parts of the parent event.