Domain security and business process security are two different systems
A field, report, or standard task is secured by a domain. Every domain has its own domain security policy, and the security groups added to that policy get view or modify access to everything the domain contains — reports, tasks, report fields, data sources, and web service operations. If a colleague can run a report or see a field and another user can't, the first thing to check is whether they belong to a security group on the domain that secures that item — not whether they're "more senior" or "in the same department."
A business process step is different: it's secured by that business process's own security policy, which controls who can initiate it, act on a step, approve, deny, cancel, correct, or reassign it — independent of any domain. This is why a user can have full access to a worker's data through domain security and still be unable to see a specific business process event: to see event step details you need to belong to a security group that can perform View All, Cancel, Correct, or Rescind on that business process's security policy, or hold View Completed Only access to a completed, non-future-dated event, or have Modify access to the Business Process Administration domain, or simply have the item in your own My Tasks right now.
Which security group type explains the gap
"Colleague can see it, I can't" is almost always a difference in which security groups the two of you belong to, and constrained group types are the usual reason two people with the same job title get different results.
| Group type | Who's a member | What they can see |
|---|---|---|
| User-based | Manually assigned individuals | Unconstrained — all data the group's domains allow |
| Role-based (constrained) | Workers whose position holds the role | Only target data in the organizations where they hold that role |
| Role-based (unconstrained) | Workers whose position holds the role | Unconstrained — every worker, not just their own org |
| Aggregation | Anyone in any of the included groups | Each member keeps their own group's constraints |
| Intersection | Only workers common to all included groups | The overlap of the included groups' constraints |
| Segment-based | Members of an existing group | Only the segments of data assigned to that membership |
The most common mismatch: two users hold the same role-based constrained security group, but one of them has the role assignment on a broader or different organization than the other, so their target access differs even though the group name is identical on both of their profiles. A user in an unconstrained security group — user-based, or a role-based group configured unconstrained — sees everything the group's domains allow, regardless of organization.
Find which domain secures the item
Run View Security for Securable Item and enter the report, task, data source, or report field by name. It returns the securing domain and every security group with permitted access to it — this is the fastest way to go from "the user can't see X" to "here is the exact list of groups that would fix it." If you need to know why a specific user does or doesn't have access to a specific delivered item rather than the general list, run Security Analysis for Securable Item and Account instead; it takes both the item and the user and shows the security policies and groups that actually grant that user access.
Find which groups the user actually belongs to
Run View Security Groups for User for both the user who can't see the item and a colleague who can. Compare the two lists against the groups View Security for Securable Item returned for the domain. The user missing access is either missing from every permitted group outright, or they're in a permitted group whose type constrains them to organizations, locations, or a compensation level that doesn't include the specific instance they're trying to view — which is a constraint problem, not a missing-permission problem, and adding them to the same group again won't fix it.
Someone edited security and forgot to activate it
Domain and business process security policy changes — adding or removing a security group, changing view to modify — are saved as pending and don't take effect until someone runs Activate Pending Security Policy Changes. Membership changes to a security group itself (adding or removing a specific worker) take effect immediately and don't need activation, which is why "I just added them to the group and they still can't see it" is often really "the policy change granting that group access to the domain is still pending." If access seems to be configured correctly but isn't working, check for pending changes before concluding the security group setup itself is wrong.
The same role, a different organization
Role-based constrained security groups don't grant access by job title — they grant it by role assignment on a specific organization, and a worker can hold a role on one organization without holding it on another. Two HR Partners can be in the identically named security group and still see different workers, because the constraint is evaluated against the organization tied to their own role assignment, not the group's name. Before assuming a security group is broken, confirm on the organization itself (Related Actions > Roles > Assign Roles, or the relevant staffing task) that both users actually hold the role on the same organization the data in question belongs to.
A custom report has its own layer on top of domain security
Custom reports aren't shared by default — only the owner can run one until it's explicitly shared on the report's Share tab, and Workday only lets you share it with users or groups who already have security access to both the report's data source and its data source filter. Report field security stacks on top of that: a user can have access to the data source and still not see a specific field, or see fewer rows than a colleague, if their security group has constrained access to the data source or to a field used in a filter. Losing a field entirely, seeing zero rows, and seeing fewer rows than someone else are three different symptoms with three different causes — missing field access, missing data source access, and constrained data source access, respectively — so match the symptom before changing the security policy.
Test it as the user, don't take their word for it
Use the Start Proxy task to proxy in as the specific user and see exactly what they see — for a report, a task, or a business process step. This is the fastest way to confirm a fix actually worked instead of asking the user to check again and relying on their description of what changed. Proxy access has to be configured through a proxy access policy, and you can create, edit, and test proxy access in any environment except a Production tenant, so this is a sandbox or preview-tenant check, not something you run against live data.
Confirm, then move on
Once View Security for Securable Item points you at a domain, View Security Groups for User confirms who's missing, and a proxy session confirms the fix, the loop is closed — you don't need to guess whether a change worked. If the same gap keeps showing up across many users on the same report or task, the fix belongs on the domain security policy or the report's data source access, not in individually adding people to a group one at a time.
kiweely can answer questions like this against a client's own tenant directly — reading which domain secures a field or report, which security groups a specific user belongs to, and where the two lists diverge — and it keeps each client's tenants and data separate, so this kind of check never crosses between accounts.