"Permission Denied (S22)" in a business-process-triggered orchestration

What S22 means

S22 is the REST API framework's Permission Denied code, returned with HTTP 403. Workday describes it as a request that is understood but can't be performed because of insufficient permissions, and the documented fix is to check the user's security policies. Your request was well formed and reached the right endpoint. The user the call ran as is not allowed to do it.

In a business-process-triggered orchestration, the hard part is that the user is usually not the person you are thinking of. Work out who the call ran as before you change any security.

Who the call ran as

Three settings decide the processing user, depending on how the orchestration was started and which credential the failing step uses.

An ISU credential on the step. If the Send Workday API Request step uses a credential of type ISU, the call runs as that Integration System User. Its permissions come from the integration system security group the ISU belongs to, not from anyone in the business process.

The initiating user, launched by a Service step. The Business Process Trigger start accepts the initiating-user authentication type as well as ISU. When an Orchestration Service step launches the orchestration, the step's settings choose the user. The default is the user who ran the previous business process step. You can also name a specific user, or take the user from a field. The default catches people out. If the step before the service step is a manager's approval, the orchestration runs with the manager's security. A manager can approve a request and still lack the domain the orchestration needs to update a record.

A launch on Cancel, Rescind, Correct or Deny. Orchestrations paired with a status change in Configure Orchestrations are launched in the context of the user on that configuration item, or, if the item has none, the User to Perform Orchestration Launches in Edit Tenant Setup - Business Processes. Workday also requires an orchestration in this pattern that makes API calls to use ISU authentication, so for a refused API call the ISU's security is the one to check.

Find the exact request that was refused

Open the Logs tab of the Analytics dashboard on the Workday Developer Site for the run's time, or click View Logs on the run in Orchestration Activity to get the logs already filtered to it. Look for the entry with a wd_response_code of 403. The entry's wd_path, wd_resource and wd_http_method tell you exactly which resource was refused and whether it was a read or a write. Note the method: the fix for a refused GET is View access, and for a POST, PUT or PATCH it is Modify access.

Don't confuse S22 with its neighbours in the same error table, because each has a different fix:

Grant the domain the endpoint needs

Each Workday REST endpoint lists the domains that secure it. The REST API Explorer on the Developer Site shows them in the endpoint description as Secured By Domain. For example, the Business Process service's GET /events/{ID} is secured by Core Navigation and Public Business Processes. Look up the endpoint from wd_path and note its domains.

Then grant the permission to the right group for the user you identified:

1. For an ISU, open the integration system security group that contains it (Workday's setup uses an Integration System Security Group (Unconstrained)). From its related actions, use Security Groups > Maintain Domain Permissions for Security Group. Workday's guidance is View or Modify on each REST domain the app calls, and Get or Put on each domain behind a SOAP operation in the orchestration.
2. For a named or derived user, find the security groups that user is in and grant the domain to one of them, or choose a run-as user who already has it. Don't add a broad role to a person to make one orchestration work.
3. Run Activate Pending Security Policy Changes. An unactivated change has no effect, and the next run fails the same way.

Two cases need more than a domain grant:

• Extend business objects. An app's own business objects are secured by the app's model security domains. Their domain security policies are created in App Manager, and the group the processing user belongs to must be on the policy with the access the call needs. If a SINGLE_INSTANCE field has secureByTarget set to true, Workday also applies the contextual security of the target instance that field points at. A user who passes the domain check can still be refused a specific record.
• Subresources. Workday notes that accessing a subresource also requires permission on the parent resource. Granting only the subresource's domain leaves the call refused.

Prove the fix

Run the business process again on a test event that reaches the same step. For an orchestration launched by a status change, you can use Relaunch on the event page instead. Then check three things in order: the run in Orchestration Activity completes without failed steps, the log line for that path now shows a 2xx wd_response_code, and the record the call was meant to read or change is correct when you read it back.

If a different call fails with S22 next, repeat the process for that path. Orchestrations often call several services, and each one can be secured by a different domain.

kiweely shortens the search for the right user and domain: it reads the tenant's security for the user or ISU the run used, maps it against the domain the endpoint needs, and then tests the business process again in the browser as that role and reads the result back. In Production it confirms the target tenant, makes one security change at a time and reads each back before the next.

For how an ISU-based WQL call is secured, see running WQL in an orchestration as an ISU. For the difference between the two kinds of policy involved, see domain vs business process security policies.