peopletechguide.com

Tag: workday business process security

  • Workday Security Model: Groups, Policies & Domains

    Security in Workday isn’t complicated.

    It’s just unforgiving.

    Make one mistake in your security configuration and you’ll either lock everyone out of critical tasks or accidentally expose sensitive data to the wrong people. There’s no middle ground.

    I’ve seen Workday implementations grind to a halt because security wasn’t configured properly from day one. HR Partners can’t see their team’s data. Payroll can’t run payroll. Managers can’t approve time off. Integration users can’t pull worker files. And every troubleshooting session starts with the same question: “Do they have the right security groups?”

    The problem isn’t that Workday security is hard to understand. The problem is that most teams never build a mental model for how it actually works. They copy security from templates, add groups when access breaks, and hope for the best.

    That creates permission sprawl. Overlapping access. Shadow permissions nobody understands. And eventually, a security audit that reveals your tenant is a mess.

    This guide gives you the mental model you need to understand Workday security from first principles. We’ll break it down into three parts: WHO gets access (Security Groups), WHAT they can do (Security Policies), and WHERE it applies (Functional Areas). Once you understand this framework, Workday security stops being mysterious and starts being predictable.

    Let’s dive in.

    The 3-Part Mental Model for Workday Security

    Every Workday security question can be answered by understanding these three components:

    1. Security Groups = WHO
    Think of these as containers of people. Security Groups define which users, workers, or roles are grouped together for access control.

    2. Security Policies = WHAT
    These define what those people can actually do. Security Policies grant or restrict permissions for viewing data, modifying records, initiating business processes, or approving transactions.

    3. Functional Areas = WHERE
    This defines where those permissions apply. Functional Areas include Domains (for data access) and Business Processes (for workflow steps and approvals).

    When you combine these three elements, you get complete access control:

    WHO (Security Group) can do WHAT (Security Policy) in WHERE (Functional Area).

    Example: HR Partners (WHO) can view and modify (WHAT) worker data in the Worker Data: Personal Information domain (WHERE).

    Let’s break down each component.

    Part 1: Security Groups (WHO Gets Access)

    Security Groups are containers of people. They define WHO is included in a particular access grant. When you assign a Security Group to a Security Policy, everyone in that group inherits the permissions defined by that policy.

    Workday provides three main types of Security Groups you’ll use in 90% of your security configurations:

    Role-Based Security Groups

    What They Are:
    Role-Based Security Groups automatically include workers based on their assigned role in Workday. Common examples include HR Partner, Payroll Partner, Benefits Partner, Recruiter, and Compensation Partner.

    How They Work:
    When you assign a worker the role “HR Partner” for a specific Supervisory Organization, they automatically become a member of the HR Partner security group for that organization. The membership is dynamic and updates automatically when role assignments change.

    Common Use Cases:

    • HR Partners: View and modify worker data for their assigned organizations
    • Payroll Partners: Process payroll and view compensation data
    • Benefits Partners: Manage benefit enrollments and eligibility
    • Recruiters: Manage requisitions, candidates, and hiring workflows
    • Compensation Partners: Run compensation reviews and approve merit increases

    Key Configuration Points:

    • Roles are assigned using the Assign Roles task
    • You can assign roles at the Supervisory Organization level (most common) or at the Company, Cost Center, or Custom Org level
    • Role assignments can be future-dated to prepare for upcoming org changes or leadership transitions
    • Membership in Role-Based Security Groups updates automatically based on current role assignments

    Example:
    Sarah is assigned the “HR Partner” role for the Engineering Supervisory Organization. She automatically becomes a member of the “HR Partner” security group. Through domain security policies, she can now view and modify worker data for all employees in the Engineering organization and its subordinate orgs.

    User-Based Security Groups

    What They Are:
    User-Based Security Groups contain specific, manually assigned users. Membership is explicit and doesn’t change unless you manually add or remove users.

    How They Work:
    You create a User-Based Security Group and manually add Workday users to it. These groups are perfect for administrators, integration system users, or small teams that need specific access.

    Common Use Cases:

    • Security Administrators: Maintain security groups and policies
    • Business Process Administrators: Configure business processes and workflows
    • Integration System Users (ISU): Run integrations and web services
    • Report Writers: Build and maintain custom reports
    • Tenant Administrators: Perform system-wide configuration and maintenance

    Key Configuration Points:

    • Created using the Create Security Group task
    • Select User-Based as the security group type
    • Add members using the Maintain Security Group Membership task
    • Membership is static unless you manually update it
    • Good for small, stable groups that need precise access control

    Example:
    You create a User-Based Security Group called “Payroll System Administrators” and manually add three payroll leads. This group gets administrative access to payroll configuration tasks and sensitive compensation data. Membership is tightly controlled and only changes when you manually add or remove users.

    Workday-Delivered Security Groups

    What They Are:
    Workday-Delivered Security Groups are preconfigured groups that Workday automatically assigns based on worker status, employment type, or specific conditions.

    How They Work:
    Workday maintains these groups automatically. You cannot manually add or remove members. Workday assigns workers to these groups based on system logic.

    Common Examples:

    • Employee as Self: Every active employee is automatically a member. This group grants workers access to view and update their own personal information, request time off, and view their pay.
    • Manager: Every worker who manages at least one direct report is automatically a member. This group grants access to approve time off, view team data, and complete manager tasks.
    • All Workers: Every active worker (employees and contingent workers) is automatically a member.
    • Contingent Workers: All contingent workers (non-employees) are automatically members.

    Key Configuration Points:

    • You cannot modify membership in Workday-Delivered groups
    • Membership updates automatically based on worker status, employment type, and organizational assignments
    • These groups are the foundation of self-service access in Workday
    • You can use these groups in your own security policies to grant broad access

    Example:
    The “Employee as Self” security group is used in domain security policies to allow workers to view and modify their own contact information, emergency contacts, and personal data. When a worker is hired, they automatically join this group. When they terminate, they automatically leave it.

    Part 2: Security Policies (WHAT They Can Do)

    Security Groups define WHO gets access. Security Policies define WHAT those people can actually do. Workday has two main types of security policies:

    Domain Security Policies

    What They Are:
    Domain Security Policies control access to data. They define which Security Groups can view, modify, or access data through web services in specific functional domains.

    How They Work:
    Each functional area in Workday (like Worker Data, Compensation, Benefits, Payroll) is divided into security domains. A domain represents a specific slice of data or functionality. Domain Security Policies grant Security Groups permission to Get (view/read) or Put (modify/write) data in those domains.

    Key Permission Types:

    • Get (View): Allows users to view data in reports, tasks, and UI screens
    • Modify: Allows users to update existing data
    • Put (Web Service): Allows integrations to read data via web services (used by ISUs)
    • Put (Web Service – Modify): Allows integrations to write/update data via web services

    Common Domains:

    • Worker Data: Personal Information (name, address, contact info)
    • Worker Data: Employment Information (hire date, termination date, job history)
    • Worker Data: Compensation (salary, bonuses, pay rates)
    • Worker Data: Benefits (enrollments, coverage, dependents)
    • Worker Data: Time Off (balances, requests, accruals)
    • Worker Data: Payroll (earnings, deductions, tax data)
    • Worker Data: Organization Assignments (Supervisory Org, Cost Center, Location)

    How to Configure:

    1. Navigate to Create Domain Security Policy
    2. Select the Domain (e.g., Worker Data: Personal Information)
    3. Add Security Groups and assign permissions:
      • View: Which groups can see this data?
      • Modify: Which groups can change this data?
    4. Configure Scope: Does this apply to all workers, or only workers in specific organizations?
    5. Activate the policy using Activate Pending Security Policy Changes

    Example:
    You create a Domain Security Policy for “Worker Data: Compensation.” You grant the Payroll Partner security group Get (View) and Modify permissions. You configure the scope so Payroll Partners can only view and modify compensation data for workers in their assigned Supervisory Organizations. Now Payroll Partners can process pay changes for their orgs but cannot see compensation data for other parts of the company.

    Business Process Security Policies

    What They Are:
    Business Process Security Policies control access to workflow steps. They define which Security Groups can initiate, approve, view, or cancel specific business processes.

    How They Work:
    Every business process in Workday (like Hire Employee, Change Job, Request Time Off, Terminate Employee) has security policies that control who can perform each step in the workflow.

    Key Permission Types:

    • Initiate: Who can start this business process?
    • Approve: Who can approve this business process at each step?
    • View: Who can see in-progress or completed business processes?
    • Cancel: Who can cancel an in-progress business process?
    • Rescind: Who can rescind a completed business process?

    Common Business Processes:

    • Hire Employee (onboarding new workers)
    • Change Job (promotions, transfers, org changes)
    • Request Compensation Change (salary adjustments, bonuses)
    • Request Time Off (vacation, sick leave)
    • Terminate Employee (offboarding)
    • Change Benefits (enrollment updates)

    How to Configure:

    1. Navigate to View Business Process
    2. Search for the business process (e.g., “Hire Employee”)
    3. Click Security Policy Configuration
    4. Define which Security Groups can Initiate, Approve, View, and Cancel
    5. Configure approval routing logic (who approves at each step?)
    6. Activate changes using Activate Pending Security Policy Changes

    Example:
    For the “Request Time Off” business process, you configure:

    • Initiate: Employee as Self (workers can request their own time off)
    • Approve: Manager (workers’ direct managers approve time off requests)
    • View: Employee as Self, Manager, HR Partner (workers, managers, and HR can view requests)

    Now workers can submit time off requests, managers approve them, and HR can track all requests across the organization.

    Part 3: Functional Areas (WHERE It Applies)

    Security Groups and Security Policies work together within specific Functional Areas. There are two main types:

    Domains (Data Access)

    Domains define WHERE data access permissions apply. Each domain represents a specific category of data in Workday.

    How Domains Work:

    • Workday organizes data into functional domains (Personal Information, Compensation, Benefits, Payroll, etc.)
    • Domain Security Policies grant Security Groups access to specific domains
    • You can scope domain access by organization (e.g., HR Partners can only see workers in their assigned orgs)

    Example Domains:

    • Worker Data: Personal Information (name, DOB, address, contact info)
    • Worker Data: Employment Information (hire date, job history, position)
    • Worker Data: Job (Job Profile, Worker Type, Time Type)
    • Worker Data: Organizations (Supervisory Org, Cost Center, Location, Company)
    • Worker Data: Compensation (salary, pay rate, bonuses, allowances)
    • Worker Data: Stock (equity grants, vesting, exercise)
    • Worker Data: Benefits (enrollments, dependents, coverage)

    Scoping Domain Access:
    When you configure a Domain Security Policy, you can limit access by organization. For example:

    • HR Partners can view Worker Data: Personal Information for workers in their assigned Supervisory Organizations only
    • Payroll Partners can view Worker Data: Compensation for workers in their assigned Cost Centers only
    • Benefits Partners can view Worker Data: Benefits for workers in their assigned Companies only

    This scoping prevents users from seeing data outside their area of responsibility.

    Business Processes (Workflow Steps)

    Business Processes define WHERE workflow permissions apply. Each business process represents a specific transaction or workflow in Workday.

    How Business Processes Work:

    • Workday organizes workflows into business processes (Hire, Terminate, Change Job, etc.)
    • Business Process Security Policies grant Security Groups permission to initiate, approve, view, or cancel specific processes
    • You can configure approval routing logic to send transactions to the right approvers

    Example Business Processes:

    • Hire Employee (onboard new workers)
    • Change Job (promotions, transfers, org changes, compensation updates)
    • Request Time Off (vacation, sick leave, personal days)
    • Terminate Employee (offboarding)
    • Request Compensation Change (merit increases, bonuses, allowances)
    • Change Benefits (enrollment updates during open enrollment or qualifying events)
    • Add Additional Job (assign workers to secondary positions)

    Approval Routing:
    Business Process Security Policies define approval routing logic:

    • Step 1: Manager approval
    • Step 2: HR approval (if job change involves promotion or grade change)
    • Step 3: Finance approval (if compensation change exceeds threshold)

    Each step can have different approvers based on conditions (e.g., only route to Finance if salary increase is greater than 10%).

    The Biggest Mistake: Permission Sprawl

    Here’s the mistake I see in almost every Workday tenant:

    Someone needs access to something. Security is locked down. The request comes to the Workday admin team: “Can you give Sarah access to view compensation data for her team?”

    The admin creates a new User-Based Security Group, adds Sarah, and grants it access through a Domain Security Policy.

    Problem solved.

    Three months later: “Can you give John the same access?”

    The admin adds John to Sarah’s group.

    Six months later: “Can you give the entire Compensation team this access?”

    The admin creates another group for the Compensation team and grants it the same access.

    One year later: “Why does Sarah still have access? She moved to a different role six months ago.”

    The admin forgot to remove her from the original group.

    This is permission sprawl. Multiple security groups granting overlapping access. No clear ownership. No documentation. No audit trail. And eventually, no one knows who has access to what or why.

    3 Moves to Prevent Permission Sprawl

    Move 1: Use Intersection Security Groups for AND Logic

    The Problem:
    You need to grant access to users who belong to MULTIPLE groups. For example: “Only users who are BOTH HR Partners AND Benefits Partners should be able to approve benefits waivers.”

    The Wrong Way:
    Create a third security group, manually add users who have both roles, and hope you remember to update it when role assignments change.

    The Right Way:
    Use an Intersection Security Group.

    How It Works:
    An Intersection Security Group automatically includes users who are members of ALL specified security groups. It’s an AND condition.

    Example:
    You create an Intersection Security Group called “HR and Benefits Partners.” You configure it to include users who are members of:

    • HR Partner security group AND
    • Benefits Partner security group

    Only users who have BOTH roles are automatically included. If a user loses one role, they automatically drop out of the Intersection group. No manual maintenance required.

    How to Configure:

    1. Navigate to Create Security Group
    2. Select Intersection as the security group type
    3. Add the security groups to intersect (e.g., HR Partner, Benefits Partner)
    4. Save the group
    5. Use this Intersection group in your security policies

    This keeps your security configuration clean, automated, and self-maintaining.

    Move 2: Treat Activate Pending Security Policy Changes Like a Deployment Step

    The Problem:
    You create a new Domain Security Policy. You configure all the permissions. You test it in your Implementation tenant. It works perfectly. You promote it to production. You recreate the exact same configuration. But nothing changes. Users still don’t have access.

    What happened?

    You forgot to Activate Pending Security Policy Changes.

    How Workday Security Activation Works:
    When you create or modify security policies in Workday, changes are saved in a pending state. They do NOT take effect until you explicitly activate them using the Activate Pending Security Policy Changes task.

    This is intentional. It lets you stage multiple security changes, review them together, and activate them all at once during a maintenance window.

    But it’s also the source of massive confusion.

    The Right Way:
    Treat Activate Pending Security Policy Changes like a deployment step. Add it to your change management checklist:

    1. Create or modify security policies
    2. Test access in Implementation tenant
    3. Document changes in your security runbook
    4. Promote to Production
    5. Recreate security changes in Production
    6. Navigate to Activate Pending Security Policy Changes
    7. Review pending changes
    8. Click OK to activate
    9. Validate access with end users

    Pro Tip:
    Schedule security activations during off-peak hours (e.g., 6:00 PM on Friday). Security activations can temporarily impact performance for large tenants.

    Move 3: Use Future-Dated Role Assignments to Prep for Reorgs

    The Problem:
    Your company is restructuring. On January 1st, 500 workers are moving to new Supervisory Organizations with new managers. Those new managers need HR Partner access for their new teams. But you can’t grant it until January 1st because the org structure hasn’t changed yet.

    So you plan to log in at midnight on New Year’s Eve to manually assign 20 new HR Partner roles.

    There’s a better way.

    The Right Way:
    Use future-dated role assignments.

    How It Works:
    When you assign a role using the Assign Roles task, you can specify an Effective Date. The role assignment doesn’t take effect until that date. On the effective date, Workday automatically activates the role and grants access.

    Example:
    On December 15th, you assign the “HR Partner” role to 20 new managers for their upcoming Supervisory Organizations. You set the Effective Date to January 1st. On January 1st at midnight, Workday automatically:

    • Activates the role assignments
    • Adds the new managers to the HR Partner security group
    • Grants them access to view and modify worker data for their new teams

    No manual intervention required. No midnight deployments. No forgotten role assignments.

    How to Configure:

    1. Navigate to Assign Roles
    2. Select the worker (future manager)
    3. Select the role (HR Partner)
    4. Select the organization (Supervisory Org they’ll manage)
    5. Set Effective Date to the date the org change takes effect (e.g., January 1st)
    6. Submit and approve the role assignment
    7. On January 1st, the role activates automatically

    This keeps your security configuration aligned with org changes and eliminates manual, time-sensitive access grants.

    Quick Security Audit Checklist

    Run this audit quarterly to keep your Workday security clean and compliant:

    ✅ What Changed Recently in Access?

    Task: Security History for Users Audit
    What It Does: Shows all security changes for specific users over a date range
    Why It Matters: Helps you track who gained or lost access and when

    How to Use It:

    1. Navigate to Security History for Users Audit
    2. Enter a Worker or leave blank to see all changes
    3. Set From Date and To Date (e.g., last 90 days)
    4. Run the report
    5. Review changes: new security group memberships, removed access, role assignments

    Red Flags to Watch For:

    • Users gaining access to sensitive domains (Compensation, Payroll) without proper approval
    • Terminated users still appearing in active security groups
    • Integration System Users (ISUs) gaining broad administrative access

    ✅ Where Is Access Coming From?

    Review Membership Overlaps and Intersections

    What to Check:

    • Which security groups does a user belong to?
    • Are they members of multiple groups granting overlapping access?
    • Are Intersection groups configured correctly?

    How to Check:

    1. Navigate to View Worker
    2. Select a worker
    3. Go to Security Profile or Related Actions > Security > View Security Groups
    4. Review all security groups the worker belongs to
    5. Identify overlaps (e.g., member of both “HR Partner” and “Payroll Partner”)

    Why It Matters:
    Overlapping memberships can grant unintended access. For example, if a user is in both “HR Partner” (view compensation) and “Payroll Partner” (modify compensation), they may have more access than intended.

    ✅ Are Integrations Over-Permissioned?

    Keep ISSG/ISU Permissions Minimal and Explicit

    The Problem:
    Integration System Users (ISUs) often get granted broad “Super User” access during implementation to “make things work.” After go-live, no one reviews or tightens the permissions. Now your integrations have access to far more data than they need, creating security and compliance risk.

    The Right Way:
    ISUs should have minimal, explicit permissions for only the domains and business processes they actually use.

    How to Audit ISU Access:

    1. Navigate to View Integration System
    2. Select an Integration System User
    3. Review Security Group Memberships
    4. Navigate to Domain Security Policies and check which domains the ISU can access
    5. Ask: “Does this integration NEED access to this domain?”

    Red Flags:

    • ISU has access to Worker Data: Compensation but the integration only reads name and email
    • ISU has access to Worker Data: Payroll but the integration only exports headcount
    • ISU has Modify permissions but the integration is read-only

    The Fix:

    • Create a dedicated ISSG (Integration System Security Group) for each integration
    • Grant only the domains and permissions the integration needs
    • Remove broad “System Administrator” or “Super User” access
    • Document ISU permissions in your integration runbook

    Common Workday Security Tasks

    Here are the key tasks you’ll use to configure and maintain Workday security:

    Security Group Management:

    • Create Security Group (build new User-Based or Intersection groups)
    • Maintain Security Group Membership (add or remove users from User-Based groups)
    • View Security Group (review group membership and configuration)

    Security Policy Configuration:

    • Create Domain Security Policy (grant access to data domains)
    • Edit Domain Security Policy (modify existing domain policies)
    • View Business Process (configure business process security and approval routing)
    • Activate Pending Security Policy Changes (activate all pending security changes)

    Role Management:

    • Assign Roles (assign Role-Based Security Group membership to workers)
    • Remove Role Assignment (remove role-based access)
    • View Role Assignments (see which workers have which roles)

    Security Auditing:

    • Security History for Users Audit (track security changes over time)
    • View Security Groups (see all groups a user belongs to)
    • Security Administration (search and manage all security groups and policies)

    Final Thoughts

    Workday security isn’t complicated. It’s just unforgiving.

    When you understand the 3-part mental model (WHO, WHAT, WHERE), security stops being mysterious:

    • Security Groups define WHO gets access
    • Security Policies define WHAT they can do
    • Functional Areas (Domains and Business Processes) define WHERE it applies

    Use this framework to build clean, maintainable security configurations:

    • Use Role-Based Security Groups for organizational access (HR Partners, Payroll Partners)
    • Use User-Based Security Groups for administrators and small teams
    • Use Intersection Security Groups for complex AND logic
    • Grant minimal, explicit permissions through Domain and Business Process Security Policies
    • Always activate changes using Activate Pending Security Policy Changes
    • Audit security quarterly to prevent permission sprawl

    Get security right from day one, and your Workday tenant stays clean, compliant, and easy to maintain. Get it wrong, and you’ll spend years untangling overlapping permissions and shadow access.

    Start simple. Stay disciplined. Document everything.

    Note: This article represents original content based on Workday HCM security configuration experience and publicly available Workday documentation. All examples and scenarios are written from practical implementation experience.

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