Week 4 of 8
Security and business processes
Workday security is configuration. Security groups get permissions through domain policies (view or modify data, get or put for integrations) and business process policies (who can initiate, approve, cancel or rescind). A policy edit does nothing until someone runs Activate Pending Security Policy Changes.
Each business process type has one security policy shared by all its definitions, and sub-processes do not inherit permissions. That is why a Hire can work end to end while one of its sub-steps silently routes to nobody.
This week: build a security test matrix with negative tests
- List your security groups by type (role-based, user-based, Workday-assigned, integration system) with one test user each.
- For every business process in scope, write at least one initiate test, one approve test and one negative test: someone who must be denied.
- Test through proxy as a real member of the group, in a non-production tenant. Never test access as an administrator.
- Log every activation with the tests you re-ran after it. If the same person edited and activated, flag it.
- Know the escape hatch: Activate Previous Security Timestamp reverts policies, not group membership, while you fix a mistake.
Number of the week
1 policy
per business process type, shared by all of its definitions. Sub-processes do not inherit permissions, so each needs its own test.
Source: Workday Education, Configurable Security Framework (2026)Use this week
- Workday Security Group & Business Process Test Matrix →
Positive and negative tests, an activation log and coverage gaps by business process, calculated.
- Defect Severity & Triage Matrix →
So a missing approval step and a typo do not get the same severity.
Next week: integrations. EIBs, connectors and Studio, and how to test them without emailing a live vendor.
Get the playbook in your inbox, one week at a time
Subscribe free and every template in the library is yours.