Workday Domain Security vs. Business Process Security Policies: Which Controls What

In Workday's configurable security framework, Domain Security Policies govern access to static or non-workflow securable items—such as delivered and custom reports, report fields, data sources, standalone setup tasks, and web service operations—while Business Process Security Policies govern transactional lifecycle events—controlling who can initiate, complete action steps, approve, cancel, rescind, or view a business process instance. Workday assigns every securable item to either a domain or a business process type (and occasionally multiple domains), and edits to either policy type remain inactive until an administrator runs Activate Pending Security Policy Changes.

Architectural comparison: Domain vs. Business Process Security Policies

Workday organizes the platform into Functional Areas (such as Staffing, Core Compensation, Benefits, and Financial Accounting), each containing both domains and business process types. You cannot move Workday-delivered securable items between domains or create new business process types, though Workday provides 200 custom domains in the System functional area for securing custom objects and dashboards.

How Domain Security Policies work

A domain groups securable items into three categories visible when you select Domain > View Security Policy from the domain's related actions:

1. Securable Actions: Standalone tasks (for example, Edit Position Restrictions or Maintain Assignable Roles) and delivered standard reports.
2. Securable Reporting Items: Data sources, data source filters, and individual report fields required to build or run custom reports.
3. Securable Integrations: REST and SOAP web service operations secured by the domain.

View/Modify vs. Get/Put permissions

Each item inside a domain specifies the minimum permission required to use it:

• View vs. Modify (UI and Reporting): Granting a security group View permission gives its members access only to items in that domain marked View. Granting Modify permission grants access to all items requiring Modify plus all items requiring View.
• Get vs. Put (Integrations): Granting Get allows an Integration System Security Group (or user group) to invoke read/extract operations. Granting Put provides write/load access as well as Get access. Items marked View Get allow groups with Get permission to read those reporting fields or actions through integrations without needing UI View permission.

Subdomain inheritance

Many domains sit in a parent-child hierarchy (viewable via the Domain Security Policies for Functional Area report). By default, a subdomain can inherit permissions from its parent domain (Status: Active - Inheriting parent permissions). If a child domain requires tighter or broader access than its parent, open the child domain policy and select Override Parent Permissions to maintain its security groups independently.

How Business Process Security Policies work

Whereas a domain controls whether you can view a field or run a standalone task, a Business Process Security Policy controls participation across the lifecycle of a workflow event. Even if an organization uses five different rule-based or org-specific definitions for Hire, all five definitions share the single Hire business process security policy. A step in a business process definition can only route to a security group if that group is first permitted on the business process security policy.

A business process security policy is divided into four main sections:

1. Who Can Start the Business Process: Maps each initiating action (UI task or inbound web service operation) to the security groups allowed to start it.
2. Who Can Do Action Steps in the Business Process: Controls which security groups can be assigned to Action steps, subprocesses, or To Do steps inside the workflow definition.
3. Who Can Delegate an Action: Specifies which security groups can delegate their inbox steps to another worker.
4. Who Can Do Actions on Entire Business Process: Grants overarching administrative or reviewer capabilities across the event:
   • Approve and Ad Hoc Approve
   • View All (view in-progress, future-dated, and completed events) and View Completed Only (view completed events that are not future-dated)
   • Cancel, Rescind, Correct, and Deny
   • Manual Advance, Manual Send Back, and Reassign Tasks

Where Domain and Business Process security intersect

In daily operations, a user often needs both policies aligned to complete their work:

• Initiating an event and seeing fields: A manager needs permission on the Change Job business process security policy to launch Change Job, and also needs View or Modify permission on the relevant Worker Data domains to see current compensation or job profile fields on the screen.
• Viewing Worker History: To see a completed staffing transaction on a worker's profile, a user needs View All or View Completed Only on the event's business process security policy and domain access to the Worker History domain items.
• Opening notification links after approving: If a security group can perform an Action or Approve step on a business process security policy but lacks View All or View Completed Only, members can view the event only while the item sits in their My Tasks inbox. Once they submit the step, clicking an email notification link to the event fails with a permission error. Run the Business Process Policy View Audit report to identify and fix groups with action/approval rights that lack view permissions.

Finding the right policy with View Security for Securable Item

Never guess which domain or business process secures a task, report field, or web service. Workday delivers diagnostic reports that trace exact policy mappings:

1. View Security for Securable Item (search shortcut: secura):
   • Enter at least three characters of the task, report, report field, data source, or web service name in the Securable Item prompt.
   • Workday returns matching items grouped by category (Tasks, Reports, Report Fields, Data Sources).
   • Click View Security next to the item to inspect the exact domain(s) or business process policy securing it, the required permission (View, Modify, Get, Put, or Initiating Action), and the currently permitted security groups.
   • Note that a single item can belong to multiple domains (audit these with the Secured Items in Multiple Domains report).
2. Security Analysis for Securable Item and Account:
   • Enter both a Securable Item and a Workday Account to see which specific security group(s) and policy path grant that user access—or confirm that no path exists.

Change control and Activate Pending Security Policy Changes

When you add or remove a security group on a domain security policy (via Edit Domain Security Policy Permissions or Maintain Permissions for Security Group) or edit a business process security policy (via Business Process Policy > Edit), Workday saves the edit in a pending state.

How activation works

• Edits require explicit activation: Pending policy changes have zero effect on live user access until an authorized administrator runs the Activate Pending Security Policy Changes task and confirms the prompt.
• Tenant-wide activation scope: Running Activate Pending Security Policy Changes activates all pending domain and business process security policy changes across the entire tenant made since the last activation, regardless of which administrator made them. You cannot cherry-pick individual pending policies during activation.
• Segregation of duties: Workday separates policy editing from activation across two domains in the System functional area: Edit Domain Security Policy Permissions is secured in the Security Configuration domain, whereas Activate Pending Security Policy Changes is secured in the Security Activation domain.
• What does NOT require activation: Changes to security group definitions or user/role memberships (such as adding a user to a User-Based group or assigning a worker to a Manager role) take effect immediately without running Activate Pending Security Policy Changes.

Auditing pending changes and reverting timestamps

Before running Activate Pending Security Policy Changes, always inspect what is queued:

• Run Domain Security Policies with Pending Changes and Business Process Security Policies with Pending Changes to review all staged edits across the tenant.
• On any individual policy, select Domain Security Policy > View Pending Changes (or Business Process Policy > View Pending Changes) to compare the active configuration against the staged edits.
• Every time you activate security changes, Workday records a security timestamp (visible in View All Security Timestamps). If an activation introduces a production defect, run Activate Previous Security Timestamp to roll back domain and business process policies to a prior timestamp. The rolled-back edits are not deleted; they return to a pending state so you can fix the mistake and run Activate Pending Security Policy Changes again.

How kiweely fits

Diagnosing why a worker or Integration System User cannot see a report column or initiate a transaction requires cross-referencing View Security for Securable Item, domain hierarchies, business process security policies, and pending activation queues. kiweely inspects your tenant's security model directly, tracing securable items to their governing domain or business process policies and highlighting missing permissions or unactivated policy changes before you deploy. Kiweely Personal is free for your Workday personal developer account and its tenant. Any other tenant needs a Personal licence, $99 a month, or a seat in your firm.

Frequently asked questions

Why did I add a security group to a domain policy, but the user still cannot access the task?

First, confirm you ran Activate Pending Security Policy Changes after editing the domain policy. Second, run View Security for Securable Item on the task to check whether the task requires Modify permission while you only granted View, or whether the task is actually an initiating action on a Business Process Security Policy rather than a standalone domain action.

Do role assignments or user-based group updates require Activate Pending Security Policy Changes?

No. Activate Pending Security Policy Changes only applies to changes made to Domain Security Policies and Business Process Security Policies. Assigning a worker to an assignable role or adding an account to a User-Based security group takes effect immediately.

Can I activate only my own pending security policy changes when another admin is also working in the tenant?

No. Activate Pending Security Policy Changes commits every pending domain and business process security policy edit in the tenant since the previous timestamp. Always run Domain Security Policies with Pending Changes and Business Process Security Policies with Pending Changes before activating to ensure you do not prematurely push another administrator's unfinished work.

Why can an approver open a task in My Tasks but get an access error when clicking the event link later?

The approver's security group is permitted on the Approve or Action step section of the Business Process Security Policy, which grants access while the task is actively in their My Tasks inbox, but lacks View All or View Completed Only under Who Can Do Actions on Entire Business Process.