Offer Business Process Guidelines

Administrator Guide

Overview

The Offer
business process is a configurable workflow used to manage all stages of extending an employment offer to a candidate. See Setup Considerations: Offers.

These are the sections in this topic:

Subprocesses

Consolidated Template

Prerequisites

Process Initiators

Limitations

Common Business Process Workflows and Guidelines

Common Business Process Workflows for Consolidated Approvals

Subprocesses

The Offer
business process can also initiate other sub-business processes. See Setup Considerations: Offers.

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 user interface. Use the template 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.

Guidelines and Best Practices

Workbook Limits: When using the

Consolidate Tasks

report to process offers in bulk, you are limited to a maximum of 200 offers per workbook.

Delegated Tasks: You can’t consolidate tasks that have been delegated.

Contingent Workers: If you use a consolidated template that includes compensation steps, you can't conditionally skip the compensation section for contingent workers. The entire consolidated block will be presented. If you need to bypass compensation steps for contingent workers, Workday recommends that you don't use a consolidated template for your Offer
business process.

Conditional Logic: For creating different offer letter documents based on criteria like location or worker type, it is a best practice to create a separate Generate Document
step for each template and use condition rules to determine which one executes. This practice is more transparent than building complex logic within a single document.

By consolidating these steps, you can significantly improve the efficiency of your recruiting team when managing complex offers.

Examples

You should consider using a consolidated template for the Offer
business process when:

Offers contain multiple compensation components. It's highly effective for offers that include not just a base salary but also elements like one-time payments, such as signing bonuses or stock grants.

You have high-volume recruiting needs. It simplifies task management by combining several offer-related tasks into a single item in My Tasks, which helps Recruiters and compensation partners manage a large number of offers more efficiently.

You want to improve the user experience. It presents all compensation-related entry fields on a single, consolidated page for the initiator, which is more intuitive and less time-consuming than completing multiple, separate steps.

Available Business Processes for Consolidation

To ensure the sub-business processes that are available for consolidation appear in the consolidated template, provide users with

View

and

Modify

access to the relevant domains.

Propose Compensation Offer/Employment Agreement
: This is the primary subprocess for defining the main compensation components of the offer, such as salary or hourly plans.

Request One-Time Payment Offer/Employment Agreement
: This subprocess is used to include any one-time payments, such as a signing bonus.

Request Stock Grant Offer/Employment Agreement
: This subprocess is for including stock grants as part of the overall compensation package.

Prerequisites

To use the Offer
business process effectively, you must first configure:

Security:

To view a list of all relevant security domains, access the

Domain Security Policies for Functional Area

report and select the Recruiting and Pre-Hire Process functional areas.

To view the security domains for a specific securable item, access the

View Security for Securable Item

report.

Business Process Definition:

Edit the Offer
business process definition to include the required steps for your organization.

Add the Offer
business process as a possible next step on one or more stages of the Job Application
business process.

Compensation:

Set up compensation components, such as one-time payment plans or stock plans, that you include in offers.

(Optional) Document Generation:

If you plan to generate offer letters from Workday, create document templates using Workday Docs for BPs or the

Create Document

task.

Process Initiators

The Offer
Business Process is initiated when:

A user with the appropriate security permissions moves a candidate to the Offer
stage within the Job Application
business process.

You configure the Job Application
business process to automatically initiate the Offer
step when a candidate is moved into a designated stage.

Limitations

The Offer
business process has several functional and process-related limitations to consider:

It is not a standalone process and must be used as a sub-process within the Job Application
business process in Workday Recruiting.

The feature to automatically initiate an offer only works if the compensation consists solely of salary or hourly plans. It does not support offers that also include allowances, bonuses, commissions, or stock.

When using workbooks to consolidate multiple offer tasks, you:

Are limited to a maximum of 200 offers per workbook.

Can’t consolidate delegated tasks.

When an approver uses the

Send Back

function on an Approval
step and includes a comment, the comment doesn’t display to the user who receives the sent-back task.

After a candidate has moved past the Offer
stage to the Employment Agreement
stage (if the customer uses both Offer
and Employment Agreement
together), you can’t:

Revert to the Offer
stage.

Use the renegotiate function for the offer.

Common Business Process Workflows and Guidelines

These are common workflow configuration paths for the Offer
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 Offer

A: Initiation

B: Action (as a sub-process of Job Application) by Recruiter or Hiring Manager

C: Action (Propose Compensation Offer) by Hiring Manager

D: Approval by Hiring Manager’s Manager

E: Generate Document by System (automated)

F: Review Document by Recruiter

G: Completion (Make Offer Decision) by Recruiter

Path 2: Offer with Multi-Level Approval Chain

This path is common in larger organizations or for senior roles that require multiple sign-offs.

A: Initiation

B: Action by Recruiter

C: Action (Propose Compensation Offer) by Hiring Manager

D: Approval by Executive or Senior Leader

E: Generate Document by System (automated)

F: Completion (Make Offer Decision) by Recruiter

Path 3: Offer with Consolidated Compensation & Electronic Signature

This workflow streamlines the process by grouping compensation tasks and integrating electronic signatures. See Set Up Adobe Sign and Set Up DocuSign.

A: Initiation

B: Action by Recruiter

C: Action (Consolidated Compensation) by Hiring Manager / Compensation Partner

D: Approval by Executive or Senior Leader

E: Review Document (Send for e-signature) by System / Candidate

F: Completion (Make Offer Decision) by Recruiter (can be automated upon candidate acceptance)

Path 4: Offer with Conditional & Rule-Based Routing

This advanced path uses condition rules to create dynamic workflows that adapt based on the specifics of the offer.

A: Initiation

B: Action by Recruiter

C: Action (Propose Compensation Offer) by Hiring Manager

D: Approval (with Condition Rule) dynamically routed based on rule. Example: Compensation Executive

E: Generate Document (with Condition Rule) by System (selects template based on rule)

F: Review Document by Recruiter

G: Completion (Make Offer Decision) by Recruiter

Common Business Process Workflows for Consolidated Approvals

Here are common workflow paths for the Offer
business process that use a Consolidated Approval
step.

Path 1: Standard Consolidated Offer Approval

This is a frequent configuration where a manager or HR partner needs to approve the complete financial picture of the offer in one step.

A: Initiation

B: Action (Propose Compensation Offer) by Hiring Manager

C: Action (One-Time Payment Offer) by Hiring Manager

D: Consolidated Approval assigned to a security group like Hiring Manager or HR Partner

E: Generate Document by System (automated)

F: Review Document by Recruiter

G: Completion (Make Offer Decision) by Recruiter

Path 2: Multi-Level Offer Approval with a Consolidated Chain

For senior roles or situations requiring multiple layers of approval, a Consolidated Approval Chain
step can be used to route the comprehensive offer package up the management hierarchy.

A: Initiation

B: Action (Propose Compensation Offer) by Hiring Manager

C: Consolidated Approval Chain assigned to a role-based group like Manager. It's configured to include the Offer and Propose Compensation Offer details. The single task is then routed up the supervisory organization of the initiator.

D: Generate Document by System (automated)

E: Review Document by Recruiter

F: Completion (Make Offer Decision) by Recruiter

Workflow Steps

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

Initiation: Step Order
: (a) Always use as the first step.
Group
: Performed by a Recruiter or HR Administrator.
Security Domain
:
Recruiter: Modify access to these domains: Candidate Data: Offer Details
, Candidate Data: Offer Initiation
, Candidate Data: Offer Initiation Business Title
, Candidate Data: Offer Initiation Weekly Hours
, Candidate Data: One-Time Payment Offer
, Candidate Data: Stock Grant Offer
, Candidate Data: Attachments
, and Manage: Candidates
.
HR Administrator: Modify access to these domains: Candidate Data: Offer Details
, Candidate Data: Offer Initiation
, Candidate Data: Offer Initiation Business Title
, Candidate Data: Offer Initiation Weekly Hours
, Candidate Data: One-Time Payment Offer
, Candidate Data: Stock Grant Offer
, Candidate Data: Attachments
, and Manage: Candidates
.

Specify
: Not applicable. This step launches the process.
Step Type Guidelines
:
Best Practices:
Assign the Initiation
step to a specific security group like Primary Recruiter instead of Initiator to avoid misrouting tasks to internal candidates.
Configure the offer to initiate automatically for simple compensation packages to increase efficiency.
Consolidate related compensation tasks (like proposing compensation, one-time payments, and stock grants) into a single user interface for a more streamlined user experience.
Use Cases: The primary use case of the initiation step is to gather and submit the core details of a job offer.
Example: Your company hires a large number of seasonal workers who are only paid an hourly wage. To streamline the process, you configure the Job Application
business process so that when a Recruiter moves a candidate to the Offer stage, the offer is automatically initiated.
Condition Rule Guidelines
:
Best Practice: To improve efficiency for offers that include multiple types of compensation, such as base salary, a one-time sign-on bonus, and a stock grant, use the Configure Consolidated Template
option for the Offer
business process. This option combines the Propose Compensation
, Request One-Time Payment
and Request Stock Grant
steps into a single, consolidated task for the initiator.
Use Case: A Recruiter needs to create a formal employment offer for the selected candidate for a software engineer position. This involves entering the proposed salary, start date, and any other initial compensation details.
Example: The Recruiter moves a candidate into the Offer
stage in the recruiting pipeline. This action automatically triggers the Offer
business process. The Recruiter receives a task in their Workday inbox titled Propose Compensation for [Candidate Name]
. In this task, they enter the proposed salary, bonus amount, and stock grant details on a single page because you enabled task consolidation.
For more information, see Concept: Initiation Step.

Action: Step Order
: (b) Typically used for initiation steps, including the first step in the process, or to launch sub-processes that require data entry.
Group
: Performed by a Recruiter, Hiring Manager, or Compensation Partner.
Security Domain
:
Recruiter: Modify access to these domains: Candidate Data: Offer Details
, Candidate Data: Offer Initiation
, Candidate Data: Offer Initiation Business Title
, Candidate Data: Offer Initiation Weekly Hours
, Candidate Data: One-Time Payment Offer
, Candidate Data: Stock Grant Offer
, Candidate Data: Attachments
, and Manage: Candidates
.
Hiring Manager: View access to Candidate Data: One-Time Payment Offer
, Candidate Data: Stock Grant Offer
, and Candidate Data: Attachments
domains.
Compensation Partner: View and often Modify access to Candidate Data: One-Time Payment Offer
and Candidate Data: Stock Grant Offer
domains.

Specify
: To configure an Action
step, you must specify the related business process it initiates. You can also configure routing modifiers to direct the task to alternate security groups if the primary security group is unassigned.
Step Type Guidelines
:
Best Practices:
Consolidate related sub-processes, such as Salary
, Bonus
, and Stock
, into a single, consolidated Action
step to improve the user experience by presenting all compensation-related tasks in one place.
Don’t route the Action
step to a user who doesn’t have the necessary security permissions to complete the action. Instead, route the step to a user who is responsible for initiating the offer process, such as a Recruiter or Hiring Manager.
Make all fields that are critical for the offer required on the Action
step to capture all necessary information before the offer is generated.
Use the data captured in the Action
step to dynamically generate the offer letter. Use conditional rules and text blocks in the document generation step to accomplish this best practice.
Use Cases: The primary use is to initiate a sub-process that requires its own set of fields and potential approvals, such as proposing compensation, requesting a one-time payment, or initiating a background check.
Example: The first step of the Offer
business process is an Action step labeled Propose Offer Details
. This step initiates the Propose Compensation Offer / Employment Agreement
sub-process, which enables the Hiring Manager to enter all relevant salary and allowance information.

Condition Rule Guidelines
:
Best Practice: Use condition rules to avoid unnecessary steps for certain populations to ensure that users only see relevant tasks.
Use Cases: Condition rules on an Action
step can determine if the step should run at all. Example: Use a rule to initiate a Request Stock Grant Action
step only if the candidate's job profile is eligible for equity.
Example: An Action
step to Initiate Background Check
is configured with the rule: (Job Profile is not Contingent Worker). The step only triggers for employee hires, skipping the background check process for temporary workers.
For more information, see Concept: Action Step.

Approval: Step Order
: Follows an Initiation
or Action
step where a decision needs to be reviewed and approved.
Group
: Performed by a Hiring Manager's Manager, HR Partner, Compensation Executive, or Department Head.
Security Domain
:
Hiring Manager’s Manager: View access to Candidate Data: One-Time Payment Offer
, Candidate Data: Stock Grant Offer
, and Candidate Data: Attachments
domains.
HR Partner: View and often Modify access to Candidate Data: Offer Details
, Candidate Data: Offer Initiation
, Candidate Data: Offer Initiation Business Title
, Candidate Data: Offer Initiation Weekly Hours
, Candidate Data: One-Time Payment Offer
, Candidate Data: Stock Grant Offer
, Candidate Data: Attachments
, and Manage: Candidates
domains.
Compensation Executive: View access to Candidate Data: One-Time Payment Offer
and Candidate Data: Stock Grant Offer
domains.
Department Head: View access to Candidate Data: One-Time Payment Offer
, Candidate Data: Stock Grant Offer
, and Candidate Data: Attachments
domains.

Specify
: You can specify the security group responsible for the approval. You can also define due dates to remind approvers and configure redirects to send the task to another user after a certain period of inactivity.
Step Type Guidelines
:
Best Practices:
Limit the number of individual Approval
steps. For sequential approvals, use an Approval Chain
step to simplify the business process definition.
Route the task to a specific security group, such as Compensation Partner or Primary Recruiter, rather than to the generic Initiator to avoid potential misrouting, especially in cases involving internal candidates or rehires.
To provide approvers with additional details, use a questionnaire within the business process. You can display the responses as supporting information on the Approval
step, giving approvers the context needed to make informed decisions.
Use a condition rule on the subsequent step in the Job Application
business process to prevent users from moving the candidate forward until the Offer
subprocess has reached its final decision or approval step to ensure all necessary approvals are completed.
Use Cases: To secure formal sign-off on the terms of the offer, such as the compensation package, start date, or job title, before it is extended to the candidate.
Example: After the Hiring Manager submits the proposed compensation, an Approval
step is routed to the HR Partner to validate that the offer aligns with internal policies and pay equity standards.

Condition Rule Guidelines
:
Best Practice: Apply condition rules to Approval
steps to enforce financial controls and signing authority policies without creating entirely separate business process definitions.
Use Cases: To create dynamic approval routing. A common use case is to require a higher level of approval for offers that exceed certain thresholds.
Example: An Approval
step for the Finance Executive has a condition rule: (Proposed Base Salary + Proposed Bonus > $200,000 USD). This step will only be inserted into the workflow if the total compensation exceeds the specified threshold, ensuring proper oversight for high-cost offers.
For more information, see Concept: Approval Step.

Approval Chain: Step Order
: Used after an Initiation
step when a management or organizational hierarchy requires multiple, sequential approvals.
Group
: This step dynamically routes up a defined hierarchy. It is not assigned to a single role but rather to a starting point in a Management Hierarchy or Organizational Hierarchy.
Security Domain
: Not Applicable.
Specify
: You must specify the basis for the chain: Management Hierarchy or Organization Hierarchy. You can also define a stopping condition, such as reaching a specific management level or role.
Step Type Guidelines
:
Best Practices:
For standard multi-level management sign-offs, such as a Manager then Manager's Manager, it's a best practice to use a single Approval Chain
step. This configuration is significantly easier to build and maintain than creating multiple, separate Approval
steps for each level.
Clearly define the hierarchy you intend to use (Management vs. Organization) to ensure approvals route as expected. Use the
View Diagram
feature of the business process to visualize the routing.
To limit the number of approvals in the chain, use an exit condition. This is the standard method for ending the chain after a specific number of approvals has been reached.
Use Cases: To automate a multi-level approval workflow that follows a direct reporting structure without having to define each approver as a separate step.
Example: An offer for a new director requires approval from the Hiring Manager's entire chain of command up to the Executive Vice President. An Approval Chain
step is configured to start with the Manager's Manager and continue up the management hierarchy until it reaches the EVP role.

Condition Rule Guidelines
:
Best Practice: Use an Approval Chain
step for standard management sign-offs. Example: Manager -> Director -> VP. This configuration is easier to maintain than creating multiple individual Approval
steps.
Use Cases: A condition rule can determine if the entire approval chain is necessary. Example: An internal hire might not require the same level of management review as an external hire.
Example: A condition rule is placed on the Approval Chain
step: (Is Internal Candidate? = False). The entire management approval chain is skipped if the candidate is an existing employee moving to a new role.
For more information, see Concept: Approval Chain Step.

Consolidated Approval or Consolidated Approval Chain: You can add a Consolidated Approval
or Consolidated Approval Chain
step in place of a standard Approval
or Approval Chain
step within the business process definition.

Consolidated Approval Step
: This step type combines multiple preceding action steps within a business process into one My Tasks item for the approver. The approver can then review and approve all the details from one screen.
Consolidated Approval Chain Step
: 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.
Best Practices

Consider adding Consolidated Approval
or Consolidated Approval Chain
steps for:
Streamlined Review: For business processes where a single approver needs to review data from multiple disparate steps, such as Job Details
, Compensation
, and One-Time Payments
, a consolidated step groups these items into a single view. This reduces context switching and ensures the approver has all necessary information before making a decision.
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.
Parallel Approvals: When a transaction needs to be approved by multiple individuals (example: all Cost Center Managers in a department), a consolidated step allows them to approve in parallel. The process can be configured to proceed after a specific number of approvers have taken action.
Organization-Based Routing: Both Consolidated Approval
and Consolidated Approval Chain
steps support organization-based routing. This allows you to route approvals up an organizational hierarchy rather than a managerial one, which is useful for approvals that need to follow a functional or regional structure.
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 and help approvers 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. Example: You configure a rule to use a
Consolidated Approval
step 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.
For more information, see Concept: Consolidated Approval Chain Step.

Generate Document: Step Order
: Typically occurs after all approvals have been received but before the offer is sent to the candidate.
Group
: Performed by a Recruiter or HR Administrator. This step can also be configured to be a system action, especially in higher volume use cases.
Security Domain
:
Recruiter: Modify access to these domains: Candidate Data: Offer Details
, Candidate Data: Offer Initiation
, Candidate Data: Offer Initiation Business Title
, Candidate Data: Offer Initiation Weekly Hours
, Candidate Data: One-Time Payment Offer
, Candidate Data: Stock Grant Offer
, Candidate Data: Attachments
, and Manage: Candidates
.
HR Administrator: Modify access to these domains: Candidate Data: Offer Details
, Candidate Data: Offer Initiation
, Candidate Data: Offer Initiation Business Title
, Candidate Data: Offer Initiation Weekly Hours
, Candidate Data: One-Time Payment Offer
, Candidate Data: Stock Grant Offer
, Candidate Data: Attachments
, and Manage: Candidates
.

Specify
: You must select the document category, such as Offer
, and the specific document template to be used.
Step Type Guidelines
:
Best Practices:
Ensure all data fields used as placeholders in your document template are available in the business process. Use the
Available Rules & Fields
tab on the business process definition to verify the fields.
To add an Approval
step for a generated offer letter so that a second person can verify the contents before it is sent to the candidate, add a Review Document
step immediately following the Generate Document
step. This new step can be routed to the appropriate security group for verification.
Use Cases: To automatically create a personalized offer letter by merging data from the business process into a standardized Microsoft Word or PDF template.
Example: After the final approval, the Generate Document
step runs automatically. It takes the Standard Professional Offer Letter
template and populates it with the candidate's name, job title, manager, location, and the approved compensation details, creating a complete PDF ready for review.

Condition Rule Guidelines
:
Best Practice: Create a separate Generate Document
step for each unique offer letter template and use condition rules to determine which one to execute. This approach is more transparent than embedding complex logic within a single document template.
Use Cases: To select the correct offer letter template based on specific attributes of the job or candidate, such as location, worker type, or union status.
Example: The business process has two Generate Document
steps.
Step 1 Rule: (Country = USA). Uses the US Offer Letter
template.
Step 2 Rule: (Country = Germany). Uses the German Offer Letter
template.
Based on the candidate's location, the system will run the correct step and generate the appropriate, legally compliant document.
For more information, see Configure Generated Documents.

Review Document: Step Order
: Immediately follows a Generate Document
step.
Group
: Performed by a Candidate as Self, Hiring Manager, or HR Partner.
Security Domain
:
Candidate as Self: View access to the Candidate Data: Offer Details
domain.
Hiring Manager: View access to Candidate Data: One-Time Payment Offer
, Candidate Data: Stock Grant Offer
, and Candidate Data: Attachments
domains.
HR Partner: View and often Modify access to Candidate Data: Offer Details
, Candidate Data: Offer Initiation
, Candidate Data: Offer Initiation Business Title
, Candidate Data: Offer Initiation Weekly Hours
, Candidate Data: One-Time Payment Offer
, Candidate Data: Stock Grant Offer
, Candidate Data: Attachments
, and Manage: Candidates
domains.

Specify
: You must specify which document should be reviewed from the list of documents generated in the business process.
Step Type Guidelines
:
Best Practices:
Assign this step to the Candidate as Self through their Candidate Home so they can review and sign the offer letter.
If your process requires an internal review of the offer letter before it is sent to the candidate, add a separate Review Document
step for an internal security group (example: a Recruiter or HR Partner) immediately after the Generate Document
step and before the candidate's Review Document
step.
If you use multiple Generate Document
steps with condition rules to create different versions of an offer letter (example: for different countries or job profiles), you must create a corresponding, separate Review Document
step for each one. A single Review Document
step can't be configured to handle multiple, conditional documents from different generation steps.
When creating condition rules for the Review Document
step, build the rules using fields from the parent business process object, such as Job Application
, not the Offer/Employment Agreement
sub-process object. The system evaluates these conditions against the parent process, and rules built on the sub-process may not work as expected.
Use Cases: To provide a candidate with a final opportunity to review and sign the generated offer letter. (Optional) Add a Review Document
step before the Review Document
step assigned to the Candidate as Self if you require another user, such as a Hiring Manager or HR Partner, to review the offer letter before the candidate.
Example: The system generates the offer letter PDF. The process then routes to a Review Document step assigned to the Candidate as Self. The candidate reviews and signs the document and then submits the step, allowing the workflow to proceed.

Condition Rule Guidelines
:
Best Practice: Use the Review Document
step in a condition rule after the Generate Document
step condition rule, in order to determine which offer letter template to use in the review.
Use Cases: Use the Review Document
step after the Generate Document
step to send the correct offer letter, based on specific attributes of the job or candidate, to the candidate for review.
Example: The business process has two Generate Document
steps.
Step 1 Rule: (Country = USA). Uses the US Offer Letter
template.
Step 2 Rule: (Country = Germany). Uses the German Offer Letter
template.
Based on the candidate's location, the system runs the correct step and generates the appropriate, legally compliant document. The Review Document
step sends the correct document to the candidate based on the condition rule.
For more information, see Set Up Review Documents Steps.

Completion: This step signifies that the main workflow is finished. Once the completion step is executed, the offer 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 offer 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.

For more information, see Concept: Completion Steps.

Integration

An Integration
step is a type of Action step that you can add to the Offer
business process definition to launch a pre-configured integration system. This step is most often used to exchange data with a third-party application as part of the offer workflow.

Step Order

: The order of the Integration step is defined by a sequential letter (example: c, d, e) in the business process definition grid. This letter determines when the step will run in relation to other steps. Example: Include an integration to a background check vendor after all internal offer approvals are complete.

Group

: Performed by an Integration System User (ISU). An ISU isn’t a person but a special user account configured with the necessary security permissions to run the integration. Specify an ISU in the

Run As User

field during step configuration.

Security Domain

ISU: View access to Job Information
, Manage: Location, Worker Data: All Positions
, Worker Data: Public Worker Reports
domains. View and Modify access to the Candidate Data: Offer Details
and Propose Compensation
domain.

Specify

: When you add an Integration
step type to the business process, the main option you must specify is the exact integration system that the step will launch. Select the integration system from a list of all available integration systems configured in your tenant.

Step Type Guidelines

Best Practices:

Security: Always use a dedicated ISU as the Run As User. This ISU should be in a security group that has been granted the minimum required permissions on the necessary domains for the integration to execute successfully.

Process Flow: Position the Integration step logically. Example: Only initiate a background check after you secure key approvals and the candidate accepts a verbal offer to avoid unnecessary costs.

Self-Contained Logic: If an integration requires complex data mapping, transformations, or needs to be chained with other integrations, build this logic into the integration's own Integration Process Event business process. This configuration keeps the primary Offer business process clean and focused on the core workflow.

Use Cases:

Automatically sending candidate information to a third-party vendor to initiate a background check or drug screening.

Triggering an integration to a relocation services provider for candidates who are eligible for relocation benefits.

Sending new hire data to an IT service management tool, such as ServiceNow, to begin the IT provisioning process for laptops and system access.

Condition Rule Guidelines

Best Practices:

Field Availability: When building a condition rule, you can only use fields that are available in the context of the business process at that specific point. Ensure the data you want to evaluate, such as job profile, location, and proposed compensation, is accessible.

Thorough Testing: Test your condition rules with multiple scenarios to confirm the integration is triggered, or correctly skipped, as expected. Use a variety of job requisitions, locations, and candidate types in your testing.

Clarity and Documentation: Give your condition rules clear, descriptive names so their purpose is immediately understandable to other administrators who may manage the business process in the future.

Use Cases:

Only running a relocation services integration if the candidate's future work location is in a different state or country from their home address.

Triggering a more extensive background check integration, but only for candidates being hired into senior leadership or finance-related roles.

Skipping the Integration step entirely for internal candidates who are simply changing roles within the company.

Example: You need to run an integration to your relocation vendor. You can create a condition rule to relocate only new hires who are eligible for a relocation package.

For more information, see:

Concept: Integration Step

Create Integration (Step)

Routing Modifiers

Use a routing modifier when a business process step needs to be directed to a specific security group in which 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.

For processes involving multiple positions, such as Start Performance Review
or Contact Change
, you can add the Primary Position or Additional Positions modifier to steps like Complete Manager Evaluation
or Get Additional Reviewers
.

For processes involving job changes, like Change Job
or Offer
, you can add the Current or Proposed modifier to approval or review steps to direct them to the appropriate manager or security group.

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:

Primary Position: Routes the step to the security group associated with the worker's primary position.

Additional Positions: Routes the step to the security group for the worker's additional position(s). If the worker has more than one additional position, the step is routed to the group for all relevant positions.

Current: In processes involving a change, this routes the step to the security group associated with the worker's current context. Example: Current manager or organization.

Proposed: In processes involving a change, this routes the step to the security group associated with the proposed new context. Example: The manager of the proposed position in a job change.

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.

Avoid Redundant Routing: Do not use routing modifiers if the additional position manager and the primary position manager are in the same organization. In this situation, Workday will route the step to both managers, creating redundancy.

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 (optional): 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:

Workers with Multiple Positions: When a worker holds more than one position, you can use a routing modifier to direct a business process step to the correct manager. Example: During a performance review for a worker on an international assignment, you can use a routing modifier to ensure the evaluation is routed to their host country manager instead of their home country manager.

Job or Organizational Changes: For business processes that involve a change in a worker's assignment, such as Change Job
or Add Additional Job
, routing modifiers are used to specify whether the step should be routed to the security group of the Current assignment or the Proposed new assignment. This ensures that the correct stakeholders (example: the receiving manager) are included in the approval process.

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. Workday allows you to 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:

Use Clear and Concise Language: The subject and body of your notification should be easy to understand. Use dynamic fields (like the candidate's name or job title) to make the notification more personal and informative.

Target the Right Audience: Be thoughtful about who receives a notification. Over-notifying users can lead to them ignoring important messages. Use security groups to target roles like Hiring Manager, Primary Recruiter, or HR Partner.

Leverage Condition Rules: Use condition rules to control when a notification is sent. This is crucial for sending the right message at the right time and avoiding unnecessary alerts.

Consider the Trigger Point: The trigger determines when the notification is sent. Common triggers include:

On Entry: Fires when a step begins.

On Exit: Fires when a step is completed.

On Status: Fires when the overall business process status changes (e.g., Completed, Canceled, Denied).

Handle External Candidates Carefully: When sending notifications to external candidates, always select the

Do Not Include Notification Details Link

checkbox. Since they don't have a Workday account, the link would lead to a login page, causing confusion.

Test Thoroughly: Use the

Preview

option to see a sample of your notification. For more complex scenarios involving condition rules, it's best to test the entire process in a sandbox environment.

Use Cases with Examples:

Scenario 1: Notify Hiring Manager of Offer Acceptance

Goal: To immediately inform the Hiring Manager when a candidate accepts their offer.

Setup:

Trigger: On Exit of the Make Offer Decision
step.

Recipient: Hiring Manager security group.

Condition Rule: Create a rule to check if the Offer Status is Accepted. This prevents the notification from firing if the offer is declined or renegotiated.

Example Message: Great news! [Candidate's Name] has accepted the offer for the [Job Title] position.

Scenario 2: Alert Recruiter to Review Onboarding Documents

Goal: After a candidate completes their onboarding questionnaires, notify the Recruiter to review the documents.

Setup:

Trigger: On Exit of the final questionnaire step.

Recipient: Primary Recruiter security group.

Condition Rule: This can be complex if there are multiple, parallel tasks. A best practice is to use an Alert instead of a custom notification, which you can configure to trigger only when all required onboarding tasks are complete.

Example Message: [Candidate's Name] has completed all pre-hire onboarding tasks. Please review the documents in their profile before moving them to Ready for Hire.

Scenario 3: Send a Revised Offer Letter Notification

Goal: Inform a candidate that a revised offer has been generated due to renegotiation.

Setup:

Trigger: On Exit of the Generate Document
step.

Recipient: Candidate as Self security group.

Condition Rule: Create a rule that checks if the business process is a renegotiation. You can do this by checking if the Renegotiate
step has been initiated in the process history.

Example Message: An updated offer letter is available for your review. Please log in to the candidate portal to view the details.

Issues and Solutions

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

Issues	Solutions
Propose Compensation Offer is not routing correctly.	Cause: This often happens when the routing on the Propose Compensation Offer step within the main Offer business process is incorrectly configured. For example, it may be routed to the Initiator by default. Solution: To fix this, edit the Offer business process definition. On the Propose Compensation Offer step, change the routing from Initiator to the specific security group that should approve it, such as Compensation Partner or Primary Recruiter. This ensures the task is routed directly to the correct approver.
Unable to correct a completed offer.	This is working as designed in Workday. Once a candidate's job application has moved to a terminal state like Ready for Hire, the Offer business process is considered complete and cannot be corrected directly. To update details from the offer (like the Hire Date), you must first cancel the Hire event. Then, use the Undo Move action to revert the candidate's status from Hire back to a stage where you can re-initiate the offer. After submitting the new offer with the corrected details, you can proceed with the hire process again.
The Offer business process is stalling.	Cause: The process has more than 72 consecutive steps that do not require manual user interaction (Examples: steps marked as Not Required or Automatically Skipped). This is a built-in Workday limitation to prevent infinite loops from incorrect configurations. Solution: A business process administrator can use the Manually Process Business Process task to advance the stalled event. For a long-term fix, reconfigure the business process to reduce the number of sequential, non-manual steps. This can be done by splitting the process into multiple, rule-based definitions.
No Deny button during Offer Approval step.	Cause: The Offer Approval step is configured, but when users view the task there is no Deny button. Solution: Working as designed. The only allowed options for Offer Approvals are: Approve Send Back Save for Later Administrators can verify the Business Process Configuration Options task and select Offer for available options for the business process. The recommendation is to utilize the Send Back option as an alternative to Deny .
Comments added during previous Offer steps are not displaying on the Generate Document step item in My Tasks.	Cause: When the Generate Document step of the Offer business process enters the comments are not visible on that step's item in My Tasks that may have been entered by a Recruiter or Manager during a previous step. The comments appear on the candidate's activity feed, but not on the item in My Tasks. Solution: Generate Document is a separate business process from Offer (even when it's a sub-process of Offer ). Process comments don't flow from one business process to another. Users entered the comments during the Offer process so they are for the Offer business process only. The Generate Document step is part of the Generate Document sub-business process of Offer , so the Generate Document process is a different business process. We expect that comments entered for the Offer business process don't display in the process history of the Generate Document sub-process and/or on the Generate Document item in My Tasks.
The Regenerate Offer Document task is not available.	Cause: The related action to regenerate an offer document may not be visible. Solution: To make this task available, a job application event must have proceeded to the Ready for Hire stage and require correction. You cannot regenerate multiple offer documents at once, and the original job application must have included the Generate Document and Review Document steps.
Inability to revert to Offer stage.	Cause: After a candidate has moved past the Offer stage to the Employment Agreement stage, if both are used together, you cannot revert to the Offer stage or use the renegotiate function. Solution: It is a best practice to complete any renegotiation of the offer before initiating the Employment Agreement step.
Document condition rules within a Generated Document subprocess are not being evaluated.	Cause: A document that has condition rules that should have been met as part of the Generate Document step within the Offer business process was supposed to be generated for the candidate to review, but did not generate. Solution: This is working as designed. Because the Generated Document step is a subprocess of the Offer business process, any condition rules created for each document specifically won't work. The solution is to create a separate step for each document with condition rules on the step instead of the document itself.