peopletechguide.com

Category: Business Process Design

  • Why Your Workday Numbers Look “Wrong”

    When Stakeholders Don’t Trust Your Workday Reports

    If you spend time in Workday reporting, you’ve probably heard some version of:

    • “This doesn’t match our spreadsheet.”
    • “Finance is showing a different total.”
    • “Can you just export it? We’ll fix it in Excel.”

    It’s easy to blame Workday when numbers don’t line up. But across different tenants, the same issues appear again and again—and they’re almost always about report design, not platform capability.​

    If your HR and Finance stakeholders regularly say the numbers “look wrong,” chances are you’re hitting one or more of these traps.

    1. You Picked the Wrong Data Source

    If the data source is wrong, everything built on top of it will be wrong too.

    Common patterns:

    • Using a data source that only includes active employees when you actually need to see all workers, including terminated or contingent workers.
    • Mixing HR and Finance data sources with different grain (for example, worker-level vs transaction-level) and then trying to reconcile totals between them.
    • Starting from a niche data source when a broader, delivered one would have been safer.​

    No amount of filters or calculated fields can fix a fundamentally mismatched source. Before building anything complex, confirm:

    • Does this source include the population you care about?
    • At what level does it store data (worker, position, event, line item)?
    • Is this the same lineage you’re comparing against elsewhere?

    If the answer is no, start over with the right source rather than patching around the wrong one.

    2. Your Filters and Prompts Are Fighting You

    Even with the right data source, filters and prompts can quietly sabotage your results.

    Typical issues:

    • Filters are applied on the wrong object; for example, filtering at a related level instead of on the primary business object.
    • Date or Effective Date isn’t prompted, so different users unknowingly compare different time windows.
    • Hidden or default filters (“Do Not Prompt at Runtime”) override what users think they’ve selected.​

    That one checkbox—whether something is prompted or not—can completely change what appears on the report.

    To debug:

    • Temporarily expose all key filters as prompts and run tests with very broad settings.
    • Check whether any underlying default filters are still restricting data, even when prompts seem open.
    • Verify that org, date, and status filters are applied where you actually expect them.

    Until filters and prompts are aligned with the intended question, stakeholders will keep seeing inconsistent results.

    3. Your Calculated Fields Are Double-Counting

    Calculated fields are powerful, but they’re also an easy way to inflate or distort totals.

    Common traps:

    • Aggregating at the wrong level when workers have multiple rows (for example, multiple positions, events, or dependents).
    • Building complex calculated fields, then reusing them everywhere without validating the logic in isolation.
    • Summing values in a matrix or pivot that already reflect aggregated or overlapping data.​

    If your math is built on noisy grain, your totals will always look suspicious.

    Safer patterns:

    • Start with a small debug report using just the fields and groups relevant to the calculation.
    • Confirm row-level behaviour: are you counting workers, events, assignments, or something else?
    • Only then roll the calculated field into your “official” reports and dashboards.

    Once you understand the grain, your numbers become much easier to defend.

    4. You’re Misusing Composite Reports

    Composite Reports have a reputation as “advanced mode,” so many teams reach for them too early.

    In reality, Composite is a specialised tool for:

    • Combining multiple report results or data sets into one “one-stop” output.
    • Handling multi-source, multi-period or multi-view scenarios that truly cannot be expressed in a single advanced report.​

    When you use Composite as your default for anything complex, you usually add:

    • More joins and relationships than you really need.
    • More prompts and filters to coordinate.
    • More performance issues and more places where numbers can drift.​

    If a single Advanced report (possibly surfaced on a dashboard) can answer the question, start there. Treat Composite as the last resort for genuinely complex needs—not as a badge of seniority.

    5. Security Is Silently Hiding Rows

    One of the most underestimated causes of “wrong” totals is security.

    Scenario:

    • An admin runs a report and sees 1,254 workers.
    • A manager runs the same report, with seemingly identical prompts, and sees 1,037.
    • Both assume the other view is wrong.

    In fact, both views might be correct—for their security.

    Because Workday enforces security at the data level, reports will naturally show different populations based on:

    • Supervisory org visibility.
    • Role-based access and domain security.
    • Field-level security and constrained data sources.​

    If you only test reports as an admin, you will miss how they behave for real users.

    Always:

    • Test key reports as different roles (HR Partner, HRBP, Manager, Finance, etc.).
    • Clearly communicate which roles a report is designed for.
    • Document whether a report is meant to be tenant-wide, region-specific, or org-specific.

    If you don’t account for security, you’ll spend hours chasing “wrong” numbers that are actually right for that user.

    A Simple Playbook to Fix “Wrong” Numbers

    When stakeholders don’t trust your reports, you don’t need a brand-new reporting strategy. You need a disciplined way to design and debug.

    Here’s a practical playbook.

    Start with the question, not the tool

    • Ask, “What decision will this report support?” before building anything.
    • Choose the simplest data source and an Advanced report that can answer that specific decision-making need.​

    Strip the report back to basics

    • Remove non-essential filters, columns, and calculated fields.
    • Run the report with broad prompts (wide date ranges, minimal org restrictions).
    • Prove that the base data set is correct first; only then add complexity.

    Test your prompts deliberately

    • Check that prompts are bound to the right underlying fields.
    • Make sure critical prompts—dates, orgs, populations—are present and, where appropriate, mandatory.
    • Look for “hidden” filters or defaults that override the user’s choices at runtime.​

    Debug calculated fields in isolation

    • Build a tiny “debug” report that exists solely to test calculated fields and groupings.
    • Compare its totals against a trusted reference (manual count, legacy report, or a smaller population).
    • Only plug complex calcs into production reports when they match reality in isolation.

    Apply this playbook consistently and two things will happen:

    1. Stakeholders will stop opening every report conversation with “These numbers look wrong.”
    2. You will become the person leaders rely on when they need numbers they can make decisions with.

    And in Workday reporting, that trust is the most valuable metric you can own.

  • Tracking Changes in Workday Business Processes

    “Who Changed the Offer BP?” – A Common Workday Problem

    Almost every Workday team has experienced this moment: recruiting suddenly stops working as expected, offers get stuck, approvers change, and someone finally asks, “Who changed the Offer business process last week?” The room goes quiet, people check emails and messages, and no one has a clear answer.

    This is not just a technical problem. It is a governance and accountability problem. When business process (BP) changes are not properly tracked, communicated, and owned, HR, Talent Acquisition, and Hiring Managers lose confidence in Workday. The system appears unpredictable and “risky,” even when the root cause is simply a missing process for change control.

    Why Workday Business Process Changes Are So Sensitive

    Business processes in Workday control the steps, routing, notifications, and validations that drive core workflows: hiring, offers, onboarding, job changes, promotions, terminations, and more. A small change in a condition, approver, or step can materially impact:

    • Who needs to approve an action.
    • How long a transaction takes.
    • Which data is required or optional.
    • Which stakeholders are notified—or not notified.

    When these changes are made quickly, without documentation or testing, they often look harmless in the moment. But a week later, when a recruiter asks why offers are stuck or a manager wonders why a new approver is suddenly in the chain, the lack of visibility becomes a major issue.

    Typical Symptoms of Poor BP Change Governance

    If your Workday tenant has weak governance around business process changes, you might notice some of these symptoms:

    • Recruiting or HR users report “something changed” in approval flow, but no one knows exactly what.
    • Approvers change without clear business agreement, creating political or compliance issues.
    • Testing happens directly in production because “it’s just a small tweak.”
    • Documentation about the current BP design is outdated, or doesn’t exist at all.
    • The same issues reappear across releases because no one tracks previous decisions.

    Over time, this erodes trust. Business users start to see Workday as a black box that “randomly changes,” even if those changes were made with good intentions.

    The Foundation: Clear Ownership and Roles

    Before getting into tools and reports, it is crucial to define who actually owns each key business process. For example:

    • HR Operations might own the Hire and Termination processes.
    • Talent Acquisition might own the Offer and Recruiting processes.
    • HR and Finance together might own Job Change and Compensation changes.

    Clear ownership means:

    • No changes to a process are made without the knowledge and approval of its owner.
    • Owners participate in design, testing, and sign-off for any configuration updates.
    • There is a known “RACI” (who is Responsible, Accountable, Consulted, and Informed) for each core BP.

    When ownership is vague, changes happen informally, through ad-hoc requests and one-off messages. When ownership is explicit, it becomes easier to implement a simple but effective change control process.

    Practical Ways to Track Who Changed What and When

    Workday provides multiple tools and logs that help teams understand configuration changes, but they only work if you build them into your operating rhythm. Depending on your tenant setup and access, you may have options such as:

    • Configuration reports that show recent changes in business processes and related objects.
    • Delivered or custom audit reports that track who made specific configuration updates and when.
    • Change tickets or requests in your ITSM tool (e.g., Jira, ServiceNow) that record the “why” behind changes.

    The key is to combine system-level visibility (who changed what, technically) with process-level governance (who approved the change, and what problem it solved). Technical logs alone are not enough; they need to be tied to a clear request and approval trail.

    A Simple Change Control Flow for Workday Business Processes

    You do not need a huge bureaucracy to manage business process changes. A lightweight change control flow is enough to avoid most issues. For example:

    1. Request
      A user identifies a problem (e.g., an approver is missing, a step is unnecessary) and submits a change request with context.
    2. Review and Design
      The Workday admin and BP owner review the request, explore options, and agree on the design.
    3. Configure in Non-Production
      The change is made in a test or sandbox tenant, not directly in production.
    4. Test with Real Scenarios
      HR, Talent, or Finance users test the change using realistic scenarios and confirm the expected behavior.
    5. Approve and Document
      The owner approves the change, and a short design note is recorded (what changed, why, and any impacts).
    6. Move to Production and Communicate
      The change is migrated, and impacted users receive a short update—especially if their approvals or steps change.

    With this simple pattern, the question “Who changed the Offer BP last week?” has a clear answer: there is a ticket, an owner, and documentation.

    Communicating Business Process Changes to Stakeholders

    Even when changes are well-controlled, they can still cause confusion if users are not informed. For Workday business process changes, communication should match the impact:

    • Small, low-impact tweaks can be summarized in a monthly “Workday changes” digest.
    • Medium-impact changes, like new approvers or extra validation steps, should be highlighted in targeted emails or intranet posts.
    • High-impact changes that affect many users or critical workflows may deserve training sessions, FAQs, or quick reference guides.

    The goal is not to flood users with technical details, but to answer their key questions: What changed? Why did it change? What do I need to do differently?

    Building Trust by Making Workday Changes Visible

    Ultimately, tracking and governing business process changes is about building trust. HR, Talent, and Finance teams are more willing to rely on Workday when:

    • They know there is a stable process for changing core workflows.
    • They can see, in plain language, what has changed and why.
    • They feel involved in design decisions rather than surprised by new behavior.

    The next time someone asks, “Who changed the Offer BP last week?”, your goal is not just to have a name. Your goal is to be able to say: “Here’s the change request, here’s who approved it, here’s the test we ran, and here’s how we communicated it.”

    That is how Workday becomes simpler, more predictable, and more trusted for HR and Finance teams.

  • 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)
    1. 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)
    1. 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
    1. 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.

  • Designing Bulletproof Workday Business Processes

    Designing Bulletproof Workday Business Processes

    Business processes (BPs) are where Workday turns static configuration into dynamic workflows: approvals, notifications, validations and automated actions. When well-designed, BPs keep transactions flowing smoothly through hires, comp changes, journals, invoices and more. When poorly designed, they create bottlenecks, bypass controls and frustrate users. The difference is intentional design, smart conditional logic and thorough edge-case testing before go-live.​

    This guide walks through practical patterns for designing business processes that work in production, not just in demos.

    Start with the “Rule of Three” for approvals

    One of the most common BP mistakes is building overly complex approval chains that slow everything down without adding meaningful control.​

    The Rule of Three:

    • Limit each business process to no more than three required approval steps for a single transaction.​
    • More than three approvals rarely add value and often create bottlenecks, leading users to find workarounds.​

    Practical application:

    • For a hire process: Manager approval → HR Partner review → Compensation approval (if needed based on level/salary).
    • For a supplier invoice: Budget owner → Finance review (if over threshold) → Controller approval (if very high value).
    • For a journal: Preparer → GL Accountant review → Controller post (if material or unusual account).​

    If you find yourself needing more steps, question whether all of them are truly required or whether some are “nice to have” that can be notifications instead of blocking approvals.​

    Use conditional logic wisely, not wildly

    Conditional logic (entry conditions, routing rules, approval thresholds) is what makes BPs flexible and powerful. But it can also become unmaintainable if overused.​​

    Best practices for conditional logic:

    • Keep entry conditions simple
      • Use no more than three entry conditions per step to avoid confusion.​
      • Make conditions self-explanatory: “Amount > $10,000”, “Country = US”, “Job Level >= VP”.​​
    • Use system-derived logic over hard-coded lists
      • Instead of listing 50 cost centers that require extra approval, create a cost center hierarchy or custom validation and route based on the hierarchy.​
      • This keeps BPs self-maintaining: when cost centers change, the hierarchy updates automatically and the BP still works.​
    • Avoid nested conditionals where possible
      • If logic becomes “if Country = US AND Job Level > 4 AND Amount > $5000 AND Department in (A, B, C)…”, break it into smaller helper fields or validations.​
      • Use calculated fields or eligibility rules to pre-compute complex logic, then reference those in the BP.​

    Clear conditional logic makes BPs understandable to business stakeholders, not just technical admins.​

    Build in segregation of duties from the start

    A BP that lets users approve their own transactions is a control failure waiting to happen.​

    Patterns to enforce SoD:

    • Exclude initiator from approval steps
      • Use Workday’s “Exclude Initiator” checkbox in routing rules so the person who starts the process cannot also approve it.​
      • This is critical for journals, supplier setups, invoices, comp changes and other high-risk transactions.​
    • Separate security for initiation vs approval
      • Design security groups so AP Specialists can create supplier invoices but only AP Managers can approve them.​
      • Similarly, GL Accountants can create journals but Controllers approve and post.​
    • Use role-based routing, not user lists
      • Route approvals to roles (Manager, Budget Owner, HR Partner) rather than named individuals so BPs do not break when people change roles.​

    SoD embedded in BP design is much stronger than manual reviews after the fact.​

    Design for exceptions and edge cases

    Most BP designs focus on the happy path: a standard hire, a normal expense, a typical invoice. But edge cases are what break BPs in production.​​

    Common edge cases to test:

    • Missing or invalid data
      • What happens if a required field is blank? If a Worktag is invalid?​​
      • Use validation rules to catch these before the BP starts, not after approvals are in flight.​
    • Org changes mid-process
      • If a worker’s manager changes while their hire or comp change is pending, who approves?​
      • Workday can route to the new manager or keep the old one; design this intentionally.​
    • Unusual amounts or dates
      • Test extremely high or low amounts, past or future effective dates, and cross-period transactions.​​
    • Multi-step dependencies
      • If Step A is skipped (because conditions were not met), does Step B still work correctly?​​
    • Proxy and delegation scenarios
      • Can approvals be delegated? If a manager is on leave, can their proxy approve? Test these workflows explicitly.​

    Edge-case testing is where you find the gaps that demos never show.​​

    Test end-to-end, not just unit steps

    A single BP rarely works in isolation; it connects to other processes, security, integrations and reporting.​​

    End-to-end testing approach:

    • Scenario-based testing
      • Define real-world scenarios: “Hire a manager-level US employee with stock options” or “Invoice a supplier for a capital project over $50K”.​​
      • Walk through the entire flow from initiation to completion, including downstream impacts (payroll, GL, project costing).​
    • Cross-module testing
      • Test how a hire BP triggers payroll setup, how a supplier invoice BP creates GL entries, how a termination BP affects benefits and final pay.​
      • These cross-module interactions are where BPs often fail because each team tested their piece in isolation.​​
    • Performance and load testing
      • Simulate high volumes: hundreds of employees submitting timesheets or expenses simultaneously, or mass comp changes during merit cycles.​
      • Identify bottlenecks and timeout risks before they hit production.​
    • Regression testing before go-live and after releases
      • Re-test critical BPs after Workday releases to ensure new features or fixes did not break your custom logic.​

    End-to-end testing catches the “it worked in the demo but failed in production” problems.​​

    Post-go-live: monitor and refine continuously

    Even bulletproof BPs need tuning after go-live as users encounter real scenarios and volumes.​

    Post-go-live practices:

    • Track BP metrics
      • Monitor approval cycle times, exception rates, abandoned processes and escalations.​
      • Identify BPs that consistently time out, get stuck or generate support tickets.​
    • User feedback loops
      • Regularly collect feedback from initiators and approvers: what is confusing? Where are bottlenecks?​
      • Use this to simplify conditional logic, clarify instructions or adjust approval routing.​
    • Quarterly BP reviews
      • Review active BPs to identify candidates for consolidation, simplification or retirement.​
      • Check if conditional logic is still relevant or if business rules have changed.​

    Treating BPs as a living product, not a static configuration, keeps them effective over time.​

    Document BPs for maintainability

    Finally, business processes are only as good as the documentation that explains them.​

    What to document:

    • Purpose and scope: what the BP does and when it triggers.
    • Approval chain and conditions: who approves under what circumstances.
    • Known exceptions and edge cases: how unusual scenarios are handled.
    • Ownership: who maintains the BP and who to contact for issues.​

    This documentation becomes critical when the original designer leaves or the organization needs to troubleshoot a production issue.​

    Designing bulletproof Workday business processes is ultimately about simplicity, clarity and thorough testing: limit approvals to what matters, use conditional logic that is self-maintaining, build in SoD from the start, test edge cases relentlessly and refine continuously post-go-live. When BPs are designed this way, they survive not just go-live but years of organizational change and Workday releases.