Workday Business Process Configuration Guide

Here’s what happens in every Workday implementation:

• Week 1: “We need to configure business processes.”
• Week 4: “Why is every hire routing to the CEO for approval?”
• Week 8: “Why aren’t managers getting notifications?”
• Week 12: “Can we add Finance approval for salary increases over $10K?”
• Week 16: “We broke something. All approvals are stuck.”

I’ve watched this pattern repeat across dozens of implementations. Teams rush to configure Business Processes without understanding how they actually work. They copy approval steps from templates, add conditions they don’t fully understand, and hope everything routes correctly.

The result? Broken approval workflows. Notifications going to the wrong people. Critical transactions stuck in someone’s inbox for weeks. And endless troubleshooting sessions trying to figure out why a simple hire took 47 days to approve.

The truth is this: Business Processes are the automation engine that powers Workday. Every hire, termination, compensation change, time off request, and org change flows through a Business Process. Get the configuration right, and workflows run smoothly. Get it wrong, and your entire tenant grinds to a halt.

This guide walks you through Business Process configuration from scratch. We’ll cover approval routing, conditional logic, notifications, security policies, and the configuration decisions that separate clean implementations from chaotic ones.

Let’s build workflows that actually work.

What Is a Workday Business Process?

A Business Process is Workday’s term for an automated workflow. It defines the steps, approvals, notifications, and conditions that govern how transactions move through your system.

Every action in Workday that requires approval or multi-step execution is controlled by a Business Process:

Common Business Processes:

• Hire Employee (onboarding new workers)
• Terminate Employee (offboarding)
• Change Job (promotions, transfers, org changes, compensation updates)
• Request Time Off (vacation, sick leave, personal days)
• Request Compensation Change (merit increases, bonuses, allowances)
• Change Benefits (enrollment updates)
• Add Additional Job (assign secondary positions)
• Change Emergency Contacts (self-service updates)
• Submit Expense Report (expense approvals)
• Create Requisition (hiring approvals)

Each Business Process controls:

• Who can initiate the transaction (Business Process Initiators)
• What approval steps are required (Step Approvals, Manager Approvals, Role Approvals)
• What conditions trigger different routing paths (Conditional Steps, Due Date Criteria)
• What notifications are sent and when (Email Notifications, To-Do Notifications)
• Who can view or cancel transactions in progress (Business Process Security Policy)

Think of a Business Process as a flowchart that Workday executes automatically. You define the flowchart. Workday follows it.

Anatomy of a Business Process

Before we configure anything, let’s understand the key components of every Business Process:

1. Business Process Type

The Business Process Type defines what kind of transaction this workflow handles. Workday provides dozens of predefined Business Process Types:

Common Types:

• Hire (for hiring workers)
• Termination (for offboarding)
• Job Change (for job, org, or compensation changes)
• Person Event (for personal data changes like address updates)
• Absence (for time off requests)
• Benefit Event (for benefits enrollment changes)

You can’t create new Business Process Types. You configure existing ones.

2. Business Process Steps

A Business Process Step is an individual action or approval in the workflow. Steps execute in sequence (step 1, then step 2, then step 3).

Common Step Types:

• Approval (someone must approve before the transaction continues)
• To-Do (someone must complete a task, but it’s not blocking)
• Notification (send an email or alert to someone)
• Condition (evaluate criteria and route accordingly)
• Review (informational step where someone can view but not approve)

Example Workflow for Hire Employee:

Step 1: HR initiates hire (Initiator = HR Partner)
Step 2: Manager approval (Approver = Hiring Manager)
Step 3: HR approval (Approver = HR Business Partner)
Step 4: Notification to IT for provisioning (To-Do = IT System Admin)
Step 5: Transaction completes and worker is hired

Each step has:

• Step Name (e.g., “Manager Approval”)
• Step Type (Approval, To-Do, Notification, etc.)
• Assignees (who gets this step in their inbox)
• Due Date (how long they have to complete it)

3. Approval Routing

Approval Routing determines WHO receives each approval step. Workday provides several routing options:

Manager Approval:

• Routes to the worker’s direct manager
• Uses the Supervisory Organization hierarchy
• Most common routing type for manager-level approvals

Role Approval:

• Routes to users assigned a specific role (e.g., HR Partner, Payroll Partner)
• Uses Role-Based Security Groups
• Good for functional approvals (HR, Finance, Legal)

Organization Owner Approval:

• Routes to the manager of a specific organization (e.g., Cost Center manager, Supervisory Org manager)
• Good for budget approvals or org-level sign-offs

Conditional Routing:

• Routes to different approvers based on criteria (e.g., salary > $100K routes to VP, salary < $100K routes to Director)
• Uses Condition Rules to evaluate logic

Static User or Group:

• Routes to a specific person or security group
• Use sparingly (hard to maintain if people change roles)

4. Conditions and Criteria

Conditions control when steps execute or which routing path the transaction takes. You define criteria, and Workday evaluates them at runtime.

Common Condition Types:

Due Date Criteria:

• Define how long someone has to complete a step
• Example: “Manager has 3 business days to approve time off”

Step Activation Criteria:

• Control whether a step executes at all
• Example: “Only route to Finance approval if salary increase > 10%”

Routing Conditions:

• Control which approver receives the step
• Example: “Route to VP if total compensation > $150K, route to Director if < $150K”

Field-Based Conditions:

• Evaluate transaction data fields
• Example: “If Supervisory Org = Sales, route to Sales VP for approval”

5. Notifications

Notifications inform users about actions they need to take or events that occurred. Workday sends notifications via:

Email:

• External email to user’s primary work email
• Includes transaction details and link to Workday

Workday Inbox:

• In-app notification in the user’s Workday inbox
• Shows as “Action Items” or “To-Dos”

Push Notifications:

• Mobile app alerts (if Workday mobile app is enabled)

When to Send Notifications:

• When a step is assigned to someone (Approval Assigned)
• When a step is completed (Approval Completed)
• When a step is overdue (Overdue Reminder)
• When the entire transaction is complete (Process Complete)

6. Business Process Security Policy

The Business Process Security Policy controls:

• Who can initiate the Business Process
• Who can approve at each step
• Who can view in-progress or completed transactions
• Who can cancel or rescind transactions

Security is configured separately from routing logic. You might route an approval to a manager, but the security policy determines whether that manager actually has permission to approve.

Step-by-Step: Configuring Your First Business Process

Let’s configure a real-world Business Process from scratch: Request Time Off.

Business Requirement

Goal: Allow employees to request time off. Managers approve. HR can view all requests. Employees get notified when requests are approved or denied.

Approval Routing:

• Employee initiates request
• Manager approves or denies
• If approved, time off is granted
• If denied, employee is notified

Notifications:

• Email to manager when request is submitted
• Email to employee when request is approved or denied

Let’s build it.

Step 1: Navigate to the Business Process

Search for View Business Process in Workday

1. In the search field, type: Request Time Off
2. Select the Request Time Off Business Process from the results
3. Click to open the Business Process Definition

You’ll see the current configuration, including all steps, approvals, and conditions.

Step 2: Create a New Business Process Definition (Optional)

If you want to create a custom variation of the Business Process (for example, different routing for different countries or organizations), you can create a new Business Process Definition.

Why Create Custom Definitions:

• Different approval routing for different regions (US vs. UK vs. India)
• Different routing for different worker types (Employees vs. Contractors)
• Different due dates or conditions based on organization

How to Create:

1. From the View Business Process screen, click Related Actions
2. Select Create Business Process
3. Choose the Business Process Type (e.g., “Request Time Off”)
4. Name your custom definition (e.g., “Request Time Off – US Employees”)
5. Configure the steps (we’ll do this next)

For this guide, we’ll edit the default Business Process Definition (applies to all workers).

Step 3: Configure Business Process Security

Before we configure steps, we need to define WHO can initiate and approve this Business Process.

1. From the View Business Process screen, scroll to Security Policy Configuration
2. Click Edit

Configure Initiators (Who Can Submit Time Off Requests):

• Initiate: Employee as Self (workers can request their own time off)
• Optionally add: Manager (managers can submit time off on behalf of their team)
• Optionally add: HR Partner (HR can submit time off for workers)

Configure Approvers (Who Can Approve Steps):

• We’ll configure this per step in the next section

Configure Viewers (Who Can View Requests):

• View: Employee as Self (workers can see their own requests)
• View: Manager (managers can see their team’s requests)
• View: HR Partner (HR can see all requests)

Configure Rescind/Cancel:

• Rescind: Employee as Self (workers can cancel their own requests before approval)
• Cancel: Manager, HR Partner (managers and HR can cancel requests)

3. Click OK to save security configuration

Step 4: Add Approval Steps

Now we’ll configure the approval workflow.

1. From the View Business Process screen, scroll to Process Steps
2. Click Edit Process (or Configure if you’re creating a new definition)

Current Steps (Default Configuration):

• You’ll see existing steps (if any). We’ll modify them to match our requirements.

Add Step 1: Manager Approval

1. Click Add Step (or edit existing manager approval step)
2. Configure step details:
   • Step Name: Manager Approval
   • Step Type: Approval
   • Assignee Type: Manager
   • Routing: Supervisory Organization Manager (routes to worker’s direct manager)
   • Due Date: 3 business days (manager has 3 days to approve)
   • Allow Delegation: Yes (manager can delegate to another manager if out of office)
   • Required: Yes (transaction cannot complete without this approval)
3. Activation Criteria (when does this step execute):
   • Leave blank (step always executes for all time off requests)
   • OR add criteria: “Only execute if Time Off > 3 days” (auto-approve short requests)
4. Click OK to save the step

Add Step 2: Notification to Employee (Approval Complete)

1. Click Add Step
2. Configure step details:
   • Step Name: Notify Employee of Approval
   • Step Type: Notification
   • Assignee Type: Initiator (send notification to the employee who submitted the request)
   • Notification Method: Email
   • Email Template: Use Workday default template or create custom template
3. Activation Criteria:
   • Trigger: When Manager Approval step is Approved
4. Click OK

Add Step 3: Notification to Employee (Denial)

1. Click Add Step
2. Configure step details:
   • Step Name: Notify Employee of Denial
   • Step Type: Notification
   • Assignee Type: Initiator
   • Notification Method: Email
3. Activation Criteria:
   • Trigger: When Manager Approval step is Denied
4. Click OK

Your workflow now looks like this:

textStep 1: Manager Approval (Approver = Manager, Due Date = 3 days)
Step 2a: Notify Employee (if approved)
Step 2b: Notify Employee (if denied)

5. Click Done to save the Business Process configuration

Step 5: Configure Notifications

Now let’s configure email notifications for each step.

1. From the View Business Process screen, scroll to Notifications
2. Click Edit Notifications

Configure Manager Notification (When Request is Submitted):

• Event: Step Assigned (Manager Approval step)
• Recipient: Manager (step assignee)
• Email Subject: “Time Off Request from [Worker Name]”
• Email Body: Include worker name, time off dates, time off type, balance available
• Include Link: Yes (link to approve/deny in Workday)

Configure Employee Notification (When Approved):

• Event: Step Completed (Manager Approval = Approved)
• Recipient: Initiator (employee)
• Email Subject: “Your Time Off Request Was Approved”
• Email Body: Include approved dates, remaining balance

Configure Employee Notification (When Denied):

• Event: Step Completed (Manager Approval = Denied)
• Recipient: Initiator (employee)
• Email Subject: “Your Time Off Request Was Denied”
• Email Body: Include reason for denial, instructions to contact manager

3. Click OK to save notification configuration

Step 6: Test the Business Process

Before activating in production, test the workflow in your Implementation Tenant or Sandbox.

Test Scenario:

1. Log in as an employee
2. Navigate to Request Time Off
3. Select time off type (Vacation)
4. Select dates (next week, 3 days)
5. Submit request

Expected Results:

• Request routes to your manager’s inbox
• Manager receives email notification
• Manager can approve or deny from email link or Workday inbox
• If approved, employee receives approval email
• If denied, employee receives denial email
• Time off balance updates automatically (if approved)

Check:

• Did the approval route to the correct manager?
• Did email notifications send correctly?
• Did the due date calculate correctly (3 business days)?
• Can the employee view the request status?
• Can HR view the request?

If everything works, you’re ready to activate in production.

Step 7: Activate Pending Changes

After configuring the Business Process, you must activate your changes.

1. Search for Activate Pending Security Policy Changes
2. Review pending changes (your Business Process configuration updates)
3. Click OK to activate

Changes take effect immediately. All new time off requests will follow your configured workflow.

Advanced Configuration: Conditional Approval Routing

Let’s add complexity. Suppose you have this requirement:

Business Rule:
“If an employee requests more than 10 consecutive days off, route to both Manager AND HR for approval. If less than 10 days, route to Manager only.”

Here’s how to configure conditional routing:

Step 1: Edit the Business Process

1. Navigate to View Business Process > Request Time Off
2. Click Edit Process

Step 2: Add Condition Rule

1. Click Add Step (before Manager Approval step)
2. Select Step Type: Condition
3. Condition Name: Check Time Off Duration
4. Criteria: Evaluate Number of Days Requested

Configure condition logic:

IF Number of Days Requested > 10:

• Route to Path A (Manager + HR Approval)

ELSE (Number of Days ≤ 10):

• Route to Path B (Manager Approval Only)

Step 3: Configure Path A (Long Time Off)

Add Step: Manager Approval

• Step Name: Manager Approval (Long Time Off)
• Assignee: Manager
• Due Date: 3 business days
• Activation Criteria: Condition = “Number of Days > 10”

Add Step: HR Approval

• Step Name: HR Approval (Long Time Off)
• Assignee: HR Partner (role-based routing)
• Due Date: 3 business days
• Activation Criteria: Condition = “Number of Days > 10” AND Manager Approval = Approved

Step 4: Configure Path B (Short Time Off)

Add Step: Manager Approval

• Step Name: Manager Approval (Short Time Off)
• Assignee: Manager
• Due Date: 3 business days
• Activation Criteria: Condition = “Number of Days ≤ 10”

Step 5: Save and Test

Test Long Time Off Request (15 days):

• Routes to Manager
• If Manager approves, routes to HR
• If HR approves, request is granted

Test Short Time Off Request (3 days):

• Routes to Manager only
• If Manager approves, request is granted (no HR step)

Advanced Configuration: Role-Based Approval Routing

Let’s configure another scenario:

Business Rule:
“For compensation changes, route to Manager first. If salary increase > 10%, route to Finance for budget approval. If salary increase > 20%, route to VP for executive approval.”

Here’s how to configure multi-level conditional routing:

Step 1: Edit Request Compensation Change Business Process

1. Navigate to View Business Process > Request Compensation Change
2. Click Edit Process

Step 2: Add Approval Steps with Conditions

Step 1: Manager Approval

• Assignee: Manager
• Activation Criteria: Always (all comp changes require manager approval)

Step 2: Finance Approval (If Increase > 10%)

• Assignee: Finance Partner (role-based security group)
• Activation Criteria:
  • Manager Approval = Approved AND
  • Percentage Salary Increase > 10%

Step 3: VP Approval (If Increase > 20%)

• Assignee: Organization Owner (Cost Center manager at VP level)
• Activation Criteria:
  • Manager Approval = Approved AND
  • Finance Approval = Approved AND
  • Percentage Salary Increase > 20%

Step 3: Test Scenarios

Scenario 1: 5% Salary Increase

• Routes to Manager only
• If Manager approves, comp change completes

Scenario 2: 15% Salary Increase

• Routes to Manager
• Routes to Finance
• If both approve, comp change completes

Scenario 3: 25% Salary Increase

• Routes to Manager
• Routes to Finance
• Routes to VP
• If all approve, comp change completes

Business Process Best Practices

1. Keep Approval Chains Short (3 Steps Maximum)

The Problem:
Teams add too many approval steps. Every transaction requires 5-7 approvals, taking weeks to complete.

The Fix:
Limit approval steps to 3 maximum. Use conditional routing to add approvals only when necessary (high-value transactions, exceptions).

Example:
Instead of: Manager → Director → VP → Finance → HR → CEO
Use: Manager → Finance (if > $10K) → VP (if > $50K)

2. Set Realistic Due Dates

The Problem:
Due dates are too short (1 day) or too long (30 days). Approvers ignore short deadlines. Long deadlines cause transactions to sit in inboxes forever.

The Fix:
Use 3-5 business days for most approvals. Use 1-2 days for urgent transactions. Use escalation if approvals go overdue.

3. Enable Delegation for Manager Approvals

The Problem:
Manager goes on vacation. All approvals sit in their inbox for 2 weeks. Team can’t take time off or complete transactions.

The Fix:
Enable Allow Delegation on manager approval steps. Managers can delegate to another manager if they’re out of office.

4. Use Role-Based Routing (Not Static Users)

The Problem:
Business Process routes approvals to “John Smith” (specific user). John leaves the company. Approvals break.

The Fix:
Route to roles (HR Partner, Finance Partner) or organization owners (Cost Center Manager), not static users.

5. Send Email Notifications for Action Items

The Problem:
Approvals sit in Workday inbox. Users don’t check Workday daily. Approvals go unnoticed.

The Fix:
Enable email notifications for all approval steps. Include a direct link to approve/deny in the email.

6. Test in Sandbox Before Activating in Production

The Problem:
You edit a Business Process in production. Routing breaks. All hires, terminations, or comp changes get stuck.

The Fix:
Always test Business Process changes in Sandbox or Implementation Tenant first. Validate routing, notifications, and security before promoting to production.

7. Document Your Business Process Configuration

The Problem:
No one knows why approvals route the way they do. When someone asks “Why does this route to Finance?”, no one has an answer.

The Fix:
Create a Business Process Documentation spreadsheet:

• Business Process Name
• Approval Steps and Order
• Routing Logic (who approves at each step)
• Conditions and Criteria
• Due Dates
• Notification Recipients
• Business Owner (who approved this configuration)

Common Mistakes and How to Avoid Them

Mistake 1: Not Activating Pending Security Policy Changes

The Problem:
You configure a Business Process. You test it. Nothing happens. Approvals don’t route correctly.

What You Forgot:
You didn’t activate pending changes. Business Process configuration changes don’t take effect until you run Activate Pending Security Policy Changes.

The Fix:
After any Business Process configuration change, navigate to Activate Pending Security Policy Changes and activate.

Mistake 2: Circular Routing Logic

The Problem:
You configure approval routing with circular logic: Step A routes to Step B, Step B routes to Step C, Step C routes back to Step A.

What Happens:
Transactions get stuck in an infinite loop. Approvals never complete.

The Fix:
Draw out your approval workflow on paper before configuring. Validate that each step has a clear path to completion (no circular references).

Mistake 3: Forgetting to Grant Security Group Permissions

The Problem:
You configure a step to route to “HR Partner” role. No one in the HR Partner security group can approve because they don’t have Business Process Security Policy permissions.

What Happens:
Approvals route to HR inbox, but HR can’t approve. Transactions get stuck.

The Fix:
Always check Business Process Security Policy configuration. Grant the security group permission to Approve at the appropriate step.

Mistake 4: Over-Relying on Static User Routing

The Problem:
You route approvals to specific users by name. Users change roles, leave the company, or go on extended leave. Approvals break.

The Fix:
Use role-based routing (HR Partner, Finance Partner) or organization owner routing (Cost Center Manager, Supervisory Org Manager). These update automatically when role assignments change.

Mistake 5: Not Testing Edge Cases

The Problem:
You test the “happy path” (manager approves, transaction completes). You don’t test denials, cancellations, or conditional routing edge cases.

What Happens:
Production issues surface when edge cases occur (manager denies, worker cancels, conditional routing fails).

The Fix:
Test ALL scenarios:

• Approval
• Denial
• Cancellation
• Delegation
• Overdue (what happens if no one approves within due date?)
• Conditional routing (both paths: condition true, condition false)

Workday Tasks for Business Process Configuration

View and Edit Business Processes:

• View Business Process (see current configuration)
• Edit Business Process (modify steps, routing, conditions)
• Create Business Process (create custom definition for specific orgs or regions)

Business Process Security:

• Edit Business Process Security Policy (configure who can initiate, approve, view, cancel)
• Activate Pending Security Policy Changes (activate configuration changes)

Testing and Validation:

• Initiate Business Process (test by submitting a transaction)
• View Event (see transaction history and routing log)
• View Inbox (check if approvals route correctly)

Reporting:

• Business Process History (audit trail of all transactions)
• Outstanding Business Processes (see stuck or overdue approvals)

Final Thoughts

Business Process configuration is where Workday’s automation power lives. Get it right, and transactions flow smoothly through approvals, notifications fire correctly, and your tenant runs like clockwork.

Get it wrong, and every hire takes 47 days, approvals route to the wrong people, and your HR team spends hours troubleshooting stuck workflows.

The keys to success:

• Understand the anatomy of a Business Process (steps, routing, conditions, notifications, security)
• Keep approval chains short (3 steps maximum)
• Use role-based routing instead of static users
• Test thoroughly in sandbox before activating in production
• Document your configuration for future maintenance

Start simple. Build one Business Process correctly. Test it. Document it. Then move to the next one.

Your future self (and your Workday admin team) will thank you.