6.1 Business Process Security Policies
Key Takeaways
- A business process security policy determines who can participate in a business process - who can initiate, approve, cancel, rescind, and view it.
- Each business process type has exactly one security policy, which secures every definition of that type.
- Edit a business process security policy through Related Actions > Business Process Policy > Edit, then run Activate Pending Security Policy Changes before editing the definition.
- The Group prompt on a definition step only offers security groups that are already on the business process security policy, so the policy must be updated first.
- The Business Process Security Policies for Functional Area report lists the description of each business process type with all of its processes and subprocesses.
Two policies, two questions
The framework chapter established the split, and it is worth restating in the form the exam uses:
| Policy | Answers |
|---|---|
| Domain security policy | Can this user see or change this data? Controls access to tasks, reports, data, and web services |
| Business process security policy | Can this user participate in this event? Controls who can initiate, approve, cancel, and rescind |
A user frequently needs both. Someone may be permitted to view compensation data through a domain policy yet unable to initiate a compensation change, because the business process security policy does not include any group they belong to. That combination is the source of a lot of "I can see it but I cannot do it" tickets.
One policy per business process type
Workday defines the business process types delivered in each functional area. Every business process type has its own business process security policy, and that policy secures the permissions members of security groups have for that type.
The rule that governs definition design: you can have multiple business process definitions for a given type, but they share a single security policy. You can route steps in different definitions to different security groups as long as those groups are included in the security policy for the business process type.
This is why the Group column prompt on a definition step only offers groups already on the policy. The definition cannot route to a group the policy does not permit.
The participation permissions
A business process security policy grants permissions such as:
| Permission | What it allows |
|---|---|
| Initiate | Start a new instance of this business process |
| Approve / act on steps | Participate in the steps the definition routes to this group |
| Delegate | Pass the ability to act on tasks to another user |
| Cancel | Stop an in-progress event |
| Rescind | Reverse an event that has already completed, rolling the data back |
| Correct | Amend event data without restarting the workflow |
| View | See business process events of this type |
Rescind and correct deserve tight control. Rescind reverses a completed transaction and rolls back its data; correct amends a transaction after the fact. Both change the record of something that already happened, so they belong to a small, deliberately chosen set of groups rather than to whoever needs to approve.
Which of these are actually available varies by business process type. The Business Process Configuration Options report shows the allowed mass actions - rescind, correct, cancel, approve - and which incomplete business processes are cancelable.
Editing a business process security policy
Workday's documented order is strict and examinable.
- From the definition's Related Actions, select Business Process Policy > Edit.
- Add or remove security groups against the permissions.
- Save. The change is pending.
- Run Activate Pending Security Policy Changes.
- Then edit the business process definition: Related Actions > Business Process > Edit Definition.
The order matters mechanically, not just procedurally. Until the policy change is activated, the security group does not appear in the definition's Group prompt. Administrators who try to edit the definition first find the group missing and conclude, incorrectly, that the group was not created properly.
Edit BP Security Policy → ACTIVATE → Edit BP Definition → Test
(who may participate) (where they act)
Finding the right policy
The Business Process Security Policies for Functional Area report provides the description of a business process type and all business processes and subprocesses for that functional area. Run it when you know the functional area but not the exact type name, or when you need to see which subprocesses a type can call - because each subprocess has its own security policy that also needs the right groups.
Subprocesses inherit nothing
A subprocess is a business process type in its own right, with its own security policy and its own definitions. Granting someone the ability to initiate the parent process does not let them act on a subprocess step. When an event stalls at what looks like a step of the parent process, check whether that step is actually an Action step launching a subprocess, and check the subprocess's own policy.
Delegation
Delegation lets a user pass their business process tasks to someone else for a period - typically for leave. Two constraints connect to material elsewhere in this guide:
- Delegation is a permission on the business process security policy, so what can be delegated is bounded by the policy.
- A user cannot start a proxy session while acting as a delegate. If you are testing delegated behavior in a nonproduction tenant, proxy and delegation cannot be combined.
Diagnosing a business process access problem
| Symptom | Likely cause |
|---|---|
| User cannot find the task to start an event | Business process security policy - no initiate permission |
| The group is missing from the Group prompt in the definition | Policy edit not activated, or group not on the policy |
| Step routes but nobody is assigned | Role assignment on the organization, not the policy |
| User can act on the step but cannot see the data on the form | Domain security policy - a field or task is secured separately |
| User cannot reverse a completed event | Rescind permission on the policy |
The third and fourth rows are the ones people confuse. An empty assignee is an organization-role problem. A blank or partial form is a domain problem. A missing task is a business process policy problem. Sorting a symptom into the right one of those three buckets is most of business process troubleshooting.
An administrator creates a new security group, then opens a business process definition to route an approval step to it. The group does not appear in the Group prompt. What is the cause?
A user can run reports showing compensation data but cannot start a compensation change event. Which policy is responsible for the restriction?
Which statement about business process security policies is correct?