4.3 Troubleshooting Security Access Issues

Start from the error, not the theory

Workday's own resolution guidance for a report access error begins with a step administrators skip: read the error message to determine which field is causing the issue. Workday usually names the securable item that failed - a report field, a task, a data source. That name is the entire starting point, because domains secure items, and you cannot look up a policy without knowing the item.

The four-step method

Step 1 - identify the securable item

From the error message, or from the object itself. If a user cannot open a task, the item is the task. If a report fails on a field, the item is that field, even when the field only appears in a filter.

Step 2 - find which domains secure it, and which groups are permitted

Two equivalent routes:

• From the item's Related Actions, select Security > View Security.
• Run the View Security for Securable Item report against the item.

Either returns the security domains securing the item and the security groups permitted on each.

Step 3 - find which groups the user belongs to

Run View Security Groups for User.

Step 4 - compare and close the gap

Compare the two lists. If nothing overlaps, you have the cause. Two supported resolutions:

• Add the user to a security group that already has access to the domain - usually correct, because it uses an existing, already-reasoned grant.
• Edit the domain security policy to include a security group that the user already belongs to - then run Activate Pending Security Policy Changes.

Prefer the first option. Adding a group to a policy widens access for every member of that group, across every application in the tenant. Adding one user to an existing group is the smaller change and is far easier to reason about later.

  ┌────────────────────────────────────────────────────────┐
  │ 1. Read the error → name the securable item            │
  │ 2. View Security for Securable Item → domains + groups │
  │ 3. View Security Groups for User → the user's groups   │
  │ 4. Compare → add user to a permitted group             │
  │              OR add a group to the policy + ACTIVATE   │
  │ 5. Test (proxy, nonproduction)                          │
  └────────────────────────────────────────────────────────┘

Two different symptoms, two different causes

This distinction resolves most real tickets, and the exam leans on it heavily.

A missing permission is binary. A constraint problem is partial. If a user can run a report and gets ten rows where a colleague gets four hundred, do not touch the domain security policy - the permission is clearly present. Look instead at whether their access comes from a constrained group and whether their role assignment covers the organizations in question.

Remember also the union rule: permissions are the union of all the user's groups. Someone seeing too much is a membership problem, and the culprit is usually an unconstrained group nobody remembered they were in.

Common causes, in the order they actually occur

1. The policy change was never activated. Somebody edited a policy and stopped. Run the activation task and check the pending list.
2. The user is not in the group they think they are in. Role assignment made on the wrong organization, made with a future effective date, or made to a worker who has since changed positions.
3. A second domain is involved. Especially in reporting: the data source domain is granted but a report field domain is not. An item can also sit in more than one domain, so access through any one is enough - which cuts both ways when you are trying to remove access.
4. The domain is suspended. Status "Suspended - Policy not enabled," typical after a release delivers a new domain.
5. Constrained group, insufficient scope. The user genuinely holds the role, just not on the organization holding the data.
6. Business process permission confused with domain permission. The user can see the data but cannot initiate or approve the event - that is a business process security policy, a different object entirely. Section 6.1 covers it.

Verifying the fix

Reports tell you what the configuration says. Proxy tells you what the user experiences. Both are worth doing, and proxy is the stronger evidence.

Recall the constraints from section 1.3: proxy access policies apply to nonproduction environments only, only unconstrained security groups can be configured with proxy access, a user cannot proxy while acting as a delegate, and proxy sessions cannot receive notifications, scheduled reports, integration output, or emailed documents. So proxy proves visibility and task access well, and proves notification behavior not at all.

Documenting what you changed

Because Sandbox is refreshed from Production, a fix proven in Sandbox must be reproduced in Production deliberately. Keep a record of the domain, the security group, the permission granted, and the activation - both so you can repeat it and so the next administrator can understand why a group is on a policy that has nothing obvious to do with its name.

Exam phrasing to watch for: an item asking what to check "first" almost always wants the diagnostic that narrows the problem - reading the error, or running View Security for Securable Item - rather than a fix. Items describing partial data want a constraint answer. Items describing a hard error want a permission answer.