Category: Configuration Best Practices

  • From Configurator to Workday Architect

    Most Workday tenants do not fail because of one bad business process or one broken report. They fail slowly—through years of ad‑hoc configuration, one‑off exceptions and “just this once” changes that accumulate into technical and functional debt. Workday’s own guidance, partner methodologies and tenant health assessments all emphasize the same shift: from configurator thinking (“how do I make this work?”) to architect thinking (“how does this design impact everything else over three years?”).​

    Here are 12 configuration principles that help you build clean, scalable tenants instead of fragile ones.

    1. Start with a strong Foundation Data Model (FDM)

    The FDM—companies, ledgers, Worktags (Cost Center, Program, Project, etc.)—is the backbone of both HCM and Financials.​

    Architect mindset:

    • Design FDM once with input from HR, Finance, and key business units; avoid letting each module invent its own structures.​
    • Keep Worktag structures simple, with clear rules for how they are used in HR and Finance; add complexity only where it enables reporting or control.​

    If the FDM is clean, downstream configuration (security, reports, integrations) becomes dramatically easier to scale.

    2. Configure for the 80%, not every edge case

    Workday is flexible enough to encode every exception, but that does not mean you should.​

    Architect mindset:

    • Design business processes and rules to handle the standard 80–90% of cases elegantly.
    • For the remaining 10–20%, use manual workarounds or clearly documented exception paths rather than embedding them in configuration.​

    This keeps business processes understandable and maintainable over time.

    3. Prefer configuration patterns over one-off rules

    Configurations tend to multiply. An architect looks for patterns that can be reused across countries, business units and modules.​

    Examples:

    • Standard approval chains for similar processes (for example, all hire‑like processes share a pattern).
    • Reusable Condition Rules and Eligibility Rules instead of copy‑pasted logic.​

    Document patterns and intentionally reuse them instead of letting new teams create their own local variants.

    4. Keep business processes lean but controlled

    Workday business processes can quickly become bloated if every stakeholder demands a new step.​

    Architect mindset:

    • Limit each process to meaningful steps: initiations, key approvals, critical notifications.
    • Use conditions to add steps only where needed (by Company, Country, Threshold) instead of building multiple similar processes.​
    • Avoid serial approval chains where parallel approvals will do; keep cycle time in mind.

    Lean processes are easier to test, explain, and adjust when organizations change.​

    5. Treat security as design, not an afterthought

    Security is not just a technical concern; it shapes HR and Finance’s day-to-day experience.​

    Principles:

    • Design role-based security groups aligned to real job functions (HR Partner, Payroll Admin, AP Specialist, HRIS Analyst) rather than individuals.​
    • Use domain security and business process security consistently across modules; avoid granting “god access” to fix short-term issues.​
    • Build in Segregation of Duties (SoD) from the start, especially for financial processes.​

    Clean security models are critical for audit, compliance, and user trust.

    6. Design for change and Workday releases

    Workday has a fast release cadence, and your tenant needs to evolve safely.​

    Architect mindset:

    • Use sandbox tenants, refresh strategies and clear promotion paths (Prototype → Test → Production) for configuration changes.​
    • Treat release notes and Workday’s Release Best Practices as part of your configuration lifecycle—plan, test and adopt, not “flip everything on in prod.”​
    • Avoid hard‑coding assumptions that break when Workday adds new fields, features or locales.

    This is how you avoid regressions every six months.

    7. Make calculated fields and reports a shared asset

    Calculated fields and custom reports often become the “shadow logic” of a tenant.​

    Architect mindset:

    • Maintain a catalog of calculated fields: purpose, owner, usage, and deprecation status.​
    • Reuse key patterns (tenure, headcount flags, manager chain, normalized demographics) instead of recreating them per report.
    • Keep “heavy” calculated fields out of operational lists where they hurt performance; use them where they matter for analytics.​

    Treat reporting and calculated fields like a product, not a dumping ground.

    8. Integrations: choose standard patterns before custom

    Workday’s Integration Cloud and Cloud Connect offerings exist to prevent over-customization.​

    Principles:

    • Use Cloud Connect and standard connectors for payroll, banks, tax, and major partners where available.​
    • Standardize on a small set of integration patterns—event-based vs snapshot, EIB vs Core Connector vs API—based on use case.​
    • Keep integration mappings aligned with FDM and avoid embedding business logic in external tools when it belongs in Workday configuration.

    This reduces long-term integration debt and fragility.

    9. Document configuration decisions, not just settings

    Tenants age, teams change, and without context, configuration becomes opaque.​

    Architect mindset:

    • Maintain decision logs: why certain designs were chosen, what alternatives were rejected, and what assumptions were made.​
    • Link decision records to actual configuration (business processes, security policies, Worktags) so future teams can understand impact.
    • Treat configuration workbooks and architectural diagrams as living artifacts, not project relics.​

    This is crucial for troubleshooting, audits, and future transformations.

    10. Test across end-to-end scenarios, not just unit steps

    Configuration rarely breaks in isolation; it breaks across process boundaries: hire to payroll, requisition to payment, project to revenue.​

    Principles:

    • Design end‑to‑end test scenarios that cross modules (HCM ↔ Payroll ↔ Time, or Procurement ↔ Projects ↔ Assets ↔ GL).​
    • Involve business users in testing so real-life exceptions and policies are surfaced.​
    • Retain a core regression suite for future releases and major changes.​

    End‑to‑end testing is where “architect thinking” reveals cross‑module impacts that configurators miss.


    11. Measure tenant health and refactor regularly

    Even with good practices, configuration drifts. A tenant health check surfaces where refactoring is needed.​

    Architect mindset:

    • Use Workday and partner health assessments to analyze configuration complexity, performance, and unused objects.​
    • Periodically retire obsolete business processes, calculated fields, reports, Worktags and security groups.
    • Watch performance metrics—report load times, integration runtimes—and adjust designs that cause inefficiencies.​

    Think of this as refactoring in software engineering: keeping the codebase clean as requirements evolve.

    12. Govern configuration like code

    Finally, treat Workday configuration with the same respect as application code.​

    Principles:

    • Implement change management: requests, impact analysis, approvals, and tracked deployments for configuration changes.​
    • Separate duties: builders, reviewers, and approvers for high‑risk changes (security, FDM, payroll, tax, critical BPs).​
    • Align with IT and risk functions so Workday is part of the organization’s broader control and architecture landscape.​

    This mindset shift—from configurator to architect—is what keeps Workday tenants clean, scalable and ready for whatever HR and Finance need next. When these 12 principles guide your decisions, Workday becomes an asset that gets better every year instead of a system that “worked fine at go‑live” and slowly decays.​

  • Fixing Bad Data in Workday Recruiting

    Most talent teams blame tools, dashboards, or “system limitations” when their recruiting numbers do not look right. But in many Workday tenants, the real problem is simpler and more dangerous: bad recruiting data. Duplicate candidates, overwritten stages, inconsistent statuses, and missing fields quietly distort every pipeline metric and hiring report.​

    You might have a great implementation of Workday Recruiting. You might have strong pipelines and carefully designed business processes. Yet if your data is messy, your reports will mislead you, your funnel analysis will be wrong, and your leaders will lose trust in Workday’s numbers.​

    Bad data is the silent killer of Workday recruiting analytics—not because Workday is weak, but because messy processes and integrations feed it the wrong inputs.

    How Bad Recruiting Data Shows Up in Workday

    Bad data in Workday Recruiting rarely announces itself. It sneaks in through everyday activity:

    • The same candidate appears multiple times under slightly different names or emails.
    • A background check tool pushes a candidate back to an earlier stage, overwriting recruiter progress.
    • Required fields are left blank, so you cannot filter, segment, or report properly.
    • Candidate sources are inconsistent, making it impossible to trust attribution and ROI.​

    On the surface, Workday still “works.” Recruiters can move candidates through stages, hiring managers can review applicants, and offers can be created. The damage only becomes visible when you try to answer questions like:

    • How many candidates did we really screen last quarter?
    • What are our conversion rates from application to offer by channel?
    • Which job boards or campaigns deliver the best hires?

    If your underlying data is inconsistent or duplicated, these answers will be wrong—or impossible to get with confidence.​

    Where the Bad Data Often Comes From

    In many Workday tenants, bad recruiting data comes from a combination of three sources:

    1. Integrations that overwrite progress
      Job boards, CRMs, and background check tools sometimes update candidate records without respecting the recruiter’s current stage. For example, an integration might reset a candidate’s pipeline step or change a status based on external events, wiping out important history.​
    2. Manual shortcuts and inconsistent practices
      Recruiters may skip fields, reuse old requisitions, or manually move candidates in ways that do not match the intended process. Under time pressure, they prioritise speed over clean data.​
    3. Lack of validation and controls in Workday
      Business processes may allow hires when key fields are missing or background checks are incomplete. Without validation steps, bad or incomplete data passes through the system unnoticed.​

    None of these issues are unique to Workday. They are design and governance problems that can be solved once they are acknowledged.

    Strengthening Data Quality Inside Workday Recruiting

    To protect your recruiting analytics, you need Workday itself to help you prevent and flag bad data. There are several ways to do this:

    • Use Workday validation and BP steps wisely
      Include validation steps in your recruiting business processes that prevent hires when key data is missing or when background checks are incomplete. Require certain fields (like overall background check status or final disposition reason) before closing a requisition or moving a candidate past critical stages.​
    • Standardise candidate stages and statuses
      Make sure your candidate pipeline stages and statuses are clearly defined, with simple guidance for when to use each one. This reduces “creative” status usage that breaks funnel reporting.​
    • Build audit and quality reports
      Create audit reports that highlight candidates with missing critical fields, inconsistent statuses, or duplicated records. Run them regularly and assign owners to clean up issues.​

    These steps help Workday become an active guardian of your data, not just a passive container.

    Smarter Integrations: Stop Overwriting Good Data

    Integrations with job boards, CRMs, and background check systems are often the biggest contributors to messy candidate data if they are not designed thoughtfully.​

    Key integration principles include:

    • Do not blindly overwrite stages
      Inbound feeds should respect the candidate’s current state in Workday. Use timestamps and “last modified” logic to avoid rolling candidates back to earlier stages just because a third-party system sends an update.​
    • Write back meaningful statuses from external tools
      Background check or assessment tools should update specific fields and trigger the right steps in Workday, rather than loosely changing a candidate’s overall status without context.​
    • Use stable IDs and keys across systems
      Align on unique identifiers (for example, combinations of email, Workday ID, and external system ID) to reduce duplicates and ensure records truly match across platforms.​

    When integrations follow these principles, they enhance your recruiting data rather than quietly corrupting it.

    Tackling Duplicate Candidates

    Duplicates are one of the most visible and frustrating recruiting data issues. They cause confusion in pipelines, double work for recruiters, and inaccurate metrics at every stage.​

    To reduce duplicates:

    • Encourage candidates to use consistent emails and profiles
      Clear messaging on career sites and portals can reduce accidental duplicates.
    • Use Workday’s duplication and merge capabilities where available
      Leverage tools and processes that help you identify and merge duplicate candidates or prospects, keeping a single, clean record.​
    • Align external systems with Workday IDs
      Feed Workday-generated candidate or worker IDs back into your CRM, talent community, and assessment tools so future interactions map to the right record.​

    Treating duplicate management as a continuous process, not a one-off cleanup, is key to keeping recruiting data usable.

    Turning Bad Data into a Fixable Problem

    The good news: messy Workday recruiting data is usually fixable with structured effort. A practical approach might include:

    • Baseline your data quality
      Use audit reports and analytics overlays to identify where your recruiting data is incomplete, inconsistent, or duplicated.​
    • Prioritise the most important fields and metrics
      Focus first on the fields that drive your core metrics: time to hire, source of hire, conversion rates by stage, diversity metrics, and quality-of-hire indicators.​
    • Clean historical data in waves
      Start with high-impact roles, regions, or time periods. Correct the worst issues, then move forward with better processes to prevent them from returning.
    • Educate recruiters and hiring teams
      Show them how their actions in Workday affect data quality and the downstream metrics leadership relies on. When they see the connection, they are far more likely to follow good practices.​

    Clean Recruiting Data = Better Hiring Decisions

    Ultimately, the goal is not to have “perfect” data for its own sake. The goal is to make better decisions about where to source, how to move candidates through the pipeline, and how to allocate recruiting resources.

    With clean Workday recruiting data, you can:

    • Trust your pipeline and funnel metrics.
    • See which channels, campaigns, and recruiters perform best.
    • Track diversity and quality-of-hire in meaningful ways.
    • Give leaders confidence that Workday reports reflect reality.​

    Bad data may be the silent killer of Workday recruiting analytics—but once you see it clearly, it becomes a problem you can systematically solve.

  • 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?

    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

    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.