How Position-Based Security Models Work in Workday

Workday security is often the first thing that gets patched together during implementation and the first thing that breaks in a live tenant. Position-based security is the architectural foundation most organisations are running on, and misunderstanding how it actually works – at the role, policy, and hierarchy level – is what causes access gaps, audit findings, and broken business process routing. This guide covers how the model works, where it fails, and what to do about it.

Why Workday Assigns Security to the Position, Not the Person

Workday’s security model is built around the idea that access follows the job, not the individual. When a role is assigned to a position, every worker who fills that position inherits that role automatically. When a worker leaves or transfers, the role does not travel with them – it stays on the position.

This has direct operational consequences for access management. During employee turnover, access provisioning and de-provisioning happen as a side effect of the staffing event rather than as a separate IT task. A worker hired into a position immediately acquires the roles assigned to that position. A worker who terminates loses those roles as soon as the termination event is processed. The position itself continues to hold the role configuration regardless of who occupies it.

During transfers, the operational logic is the same. When a worker moves from one position to another through a job change event in Workday, they lose the security roles attached to the originating position and gain the roles attached to the new one. This transition is not always instantaneous in terms of effective dates, which is a point administrators often miss when troubleshooting access during mobility periods.

The alternative model – assigning roles directly to workers – exists in Workday but creates governance problems. Worker-level assignments do not follow position logic and require manual intervention to reverse, which in practice means they accumulate over time, particularly in organisations with high internal mobility.

The Role of Supervisory Organisations in Position-Based Security

Every position in Workday exists within a supervisory organisation. The supervisory organisation is not just an HR structure – it is the primary dimension that constrains what a role holder can see and act on.

When a constrained security role is assigned to a position, the scope of that role is bounded by the supervisory organisation in which the role assignment is made. A manager with a constrained Manager role in a given supervisory organisation can take actions on the workers and positions within that organisation. That same manager cannot take the same actions on workers in a peer supervisory organisation unless a separate role assignment exists there.

This is the mechanism that allows Workday to give multiple managers the same named role without giving them identical access. The role name is the same; the organisational context determines the actual data scope. Understanding this distinction is essential when troubleshooting why two users with the same security role report different access levels. The answer is almost always that their positions sit in different supervisory organisations, or that the role is constrained in one context and unconstrained in another.

Constrained vs Unconstrained Role-Based Security Groups

Workday distinguishes between two fundamental types of role-based security groups: those that are constrained by organisational membership and those that are not.

A constrained security group ties the scope of access to a specific organisational context. The canonical example is the Manager security group. A constrained Manager role assigned to a position in a supervisory organisation gives the holder access to manage workers within that organisation’s scope. Move the position to a different organisation and the scope changes accordingly. Assign the role in a second organisation and the scope expands to include both.

An unconstrained security group has no organisational scope applied. Access is global across the tenant. The canonical example is the HR Administrator security group. An unconstrained role assigned to a position means the holder can perform the permitted actions on any worker in the system, regardless of what supervisory organisation that worker belongs to.

The governance risk of misconfiguring one type as the other is significant. Assigning an unconstrained role when a constrained one was intended grants system-wide access rather than scoped access. In an audit context, this registers as excessive privilege. In a data privacy context, it means a department-level administrator can potentially view or act on workers across the entire organisation, which in a UK or EU context can create GDPR compliance exposure. The misconfiguration is also easy to miss in routine security reviews because the role name is the same in both configurations – only the security group type and its organisational qualifier reveal the difference.

How Role Inheritance Works Across the Supervisory Hierarchy

Role inheritance in Workday flows down the supervisory hierarchy. When a role is assigned to a position in a parent supervisory organisation, positions in subordinate organisations within that hierarchy also fall within scope for certain role types, depending on how the assignment is configured.

This means a senior HR Business Partner role assigned at a regional supervisory organisation level may have access to worker data across all sub-organisations under that regional node. This is the intended behaviour for many administrative roles, but it requires that the hierarchy itself is structured correctly. If a sub-organisation is incorrectly parented – connected to the wrong node in the hierarchy – the role holder may gain unintended scope or lose intended scope.

Breaking inheritance refers to a configuration state where the expected role assignment does not propagate down to subordinate organisations. This typically occurs when a position is moved to a different supervisory organisation without re-establishing the relevant role assignments, or when the hierarchy is restructured without updating the security model to match. The result is that role holders lose access to portions of the organisation they should be covering, which manifests as workers becoming inaccessible in business processes or task routing failing silently.

Identifying and correcting broken inheritance is one of the core activities in Workday post-go-live security role review and optimisation work. It requires cross-referencing the current supervisory hierarchy structure against the role assignment map and identifying mismatches. Workday’s security analysis reports, particularly the View Security for Securable Item task, are the starting point for this work.

What Happens When a Position Is Vacated

When a position becomes vacant – whether through termination, transfer, or leave – the role assignments on that position do not disappear. The position continues to hold whatever roles were configured on it. What changes is that no worker is currently filling the position, which means no individual currently derives access from those role assignments.

For business process routing, this matters. If a business process is routed to a role held by a vacant position, the routing may stall or fail, depending on how the process is configured. This is a common issue when a manager role position goes vacant unexpectedly and approval workflows sit without an active recipient.

Workday provides the Assign Roles task specifically for managing role assignments during and after staffing events. From this task, an administrator has three options. The first is to leave the role on the position as configured, which is appropriate when the position is expected to be filled quickly and the role assignment is correct. The second is to remove the role from the position temporarily, which makes sense when the position will remain vacant for an extended period and the role’s absence from routing needs to be actively managed through other means. The third is to assign an interim role to a different position holder to cover the gap, which is the standard approach when critical business process routing cannot tolerate a delay.

Which option to choose depends on the role type, the criticality of the processes it is involved in, and the expected timeline for filling the position.

Domain Security Policies and Business Process Security Policies

Position-based roles do not grant access on their own. Access in Workday is mediated through security policies, of which there are two primary types: domain security policies and business process security policies.

A domain security policy controls access to data and functional areas within Workday. Each domain has a set of allowable operations: View, Modify, Get, and Put. View and Modify apply to what a user can see and change in the user interface. Get and Put are the equivalent operations for integration and web service access. When a role-based security group is granted View access to a domain, every position holder with that role can see the relevant data. Without a domain policy granting access, the role alone does nothing.

A business process security policy controls who can initiate, approve, or take action within a given business process. Routing steps in business processes reference security groups. If the security group referenced in a routing step has no current members – because the position holding the relevant role is vacant, because the role was removed from the position, or because the security group was not attached to the correct domain policy – the process will fail to route correctly. This is one of the most common operational failures in live Workday tenants and is almost always traced back to a broken connection between the position-based role assignment and the security policy configuration.

Understanding this connection is foundational for Workday HCM configuration and business process design work. Troubleshooting a routing failure means checking the business process security policy first, then tracing back to the security group, then checking whether the relevant role is currently assigned to an active position within the correct organisational scope.

Separation of Duties in a Position-Based Model

Separation of duties in Workday is enforced through the security model by identifying combinations of roles or domain permissions that, when held by the same position or the same individual, create a control risk. The canonical SoD conflict is a position that holds both the ability to create payroll input and the ability to approve payroll input, which in a financial controls context represents a single point of manipulation.

In a position-based model, SoD conflicts are primarily a function of which roles are assigned to positions and which domain permissions those roles carry. Workday flags SoD conflicts at the role assignment stage through its security audit functionality. When an administrator attempts to assign a role to a position that would create a conflict with an existing assignment, Workday can surface a warning, depending on how SoD rules have been configured in the tenant.

The critical point that administrators often miss is that SoD is not a one-time configuration task. It requires ongoing monitoring. Organisational restructures, role reassignments, and changes to business process configurations can all create new conflicts that did not exist at the time of the original security review. The Workday Security Analysis worklet and the Security Audit Logs report are the primary tools for identifying current SoD exposure in a live tenant. Running these reviews on a defined schedule – particularly after any significant security configuration change or organisational restructure – is the standard for maintaining a defensible SoD posture.

Step-by-Step Configuration Workflow for Assigning Roles to Positions

Role assignment in Workday follows a defined sequence. Deviating from this sequence or skipping steps is the most common source of configuration errors in live tenants.

Identifying and Maintaining Assignable Roles

The first step is to confirm that the role you intend to assign is marked as assignable. Use the Maintain Assignable Roles task to review which roles are available for position assignment. Roles that are not marked as assignable cannot be attached to positions through the standard role assignment workflow.

Creating the Security Group

If a new security group is required, use the Create Security Group task. At this stage, you must determine whether the group is constrained or unconstrained. This decision cannot be changed after the security group is created without significant rework, so it must be made deliberately based on the intended scope of the role.

Attaching the Security Group to Policies

Once the security group exists, it must be attached to the relevant domain security policies and business process security policies. Attaching a security group to a domain policy requires specifying the permission level – View, Modify, Get, or Put – that the group should have on that domain. Attaching it to a business process security policy requires specifying which step or steps the group participates in.

Assigning the Role to the Position

Role assignment to a position is done through the Assign Roles task on the position record or through the Maintain Role Assignment for Position task. The assignment specifies the security group and the effective date.

Activating Pending Security Policy Changes

This is the step most often missed during urgent configurations. Any change to a security policy – including attaching a new security group – enters a pending state. The changes do not take effect until the Activate Pending Security Policy Changes task is run. Running this task applies all pending changes simultaneously and is required before any new access is actually granted. Forgetting this step is the single most frequent reason a correctly configured role assignment does not produce the expected access.

Common Configuration Errors Found in Live Tenants

The most prevalent error in live Workday tenants is a security role assigned directly to a worker rather than to their position. This often happens as a workaround during go-live when a position was not yet created or when an urgent access need arose. Worker-level assignments do not follow position logic, so when the worker transfers or terminates, the assignment remains. Over time, these accumulate and create access that no one explicitly decided to grant.

Broken inheritance, described in the role inheritance section above, is the second most common finding. It manifests as users losing access to sub-organisations they previously could see, usually after an organisational restructure that moved supervisory organisations without updating role assignments.

Unconstrained roles used in constrained contexts represent the third major error type. This is most often found when a role was initially set up for a single administrator and then later extended to a position whose holder should only have scoped access. The access works, but it is broader than intended.

Stale role assignments after restructuring are the fourth category. These are assignments that were valid when made but no longer reflect the current organisational structure. A role assigned to a position that has since been moved to a different supervisory organisation may retain its original scope configuration even though the organisational context has changed, producing access that is either over-scoped or under-scoped relative to the current structure.

How to Review and Remediate Security After an Organisational Restructure

An organisational restructure in Workday is almost always a security event, even when it is not treated as one. Supervisory organisation changes, position moves, and manager changes all affect the scope of constrained security roles. Treating a restructure as purely an HR configuration task without a corresponding security review is what causes the access drift described in the previous section.

The review process should begin with a pull of the current role assignment map across all affected supervisory organisations. Workday’s View Workday Account security report and the Security Group Membership report are the starting points. From these, you can identify which positions hold which roles and cross-reference against the new organisational structure to find mismatches.

Remediation follows the same workflow as initial configuration: adjusting role assignments on positions, updating security group policy attachments where necessary, and activating pending security policy changes. Any worker-level assignments surfaced during the review should be evaluated and, where appropriate, migrated to position-level assignments.

Documentation of the changes made during remediation is important for audit purposes. Workday’s Security Audit Logs report provides a record of security configuration changes and is the primary source for demonstrating that access changes were deliberate and authorised.

For organisations managing complex restructures or multi-country deployments, ongoing Workday security governance and post-go-live support provides the structured review cadence that prevents access drift from accumulating between formal audit cycles.

Frequently Asked Questions

If a worker transfers to a new position, do they lose their current security roles automatically?

Yes. In a position-based security model, role assignments belong to the position, not the worker. When a worker transfers to a new position through a job change event, they stop deriving access from the roles on their originating position and begin deriving access from the roles on their destination position. The transition is governed by the effective date of the job change. There is a caveat: any role assignments that were made directly to the worker rather than to their position will persist through the transfer and must be removed manually. This is one of the primary reasons worker-level assignments create governance problems over time.

What happens to business process routing when a position with a Manager role goes vacant?

Business process routing stalls or fails when it reaches a step assigned to a role with no current occupant. If the routing step is configured to go to the Manager role and the manager position is vacant, Workday has no active role member to route to. Depending on the business process configuration, this may result in the task sitting indefinitely in a system queue, generating an error, or escalating if an escalation path is defined. The standard mitigation is to use the Assign Roles task to assign the Manager role to an interim position holder for the duration of the vacancy, or to temporarily reroute the affected business processes to an alternative role with active membership.

Can the same security role be assigned to multiple positions in the same supervisory organisation?

Yes. There is no system constraint that prevents the same security role from being assigned to multiple positions within the same supervisory organisation. This is a legitimate configuration in organisations where multiple positions share the same functional responsibilities – for example, multiple HR coordinator positions each needing the same HR Partner role. The security group membership simply includes all positions holding that role within the relevant organisational scope.

What is the difference between a constrained and unconstrained security group in Workday?

A constrained security group limits the scope of access to the organisational context in which the role is assigned. An unconstrained security group grants access across the entire tenant without any organisational boundary. The Manager security group is the canonical example of a constrained group: a manager’s access is limited to the workers within their supervisory organisation. The HR Administrator security group is a common example of an unconstrained group: an HR administrator can typically access worker data across all organisations. The determination of constrained versus unconstrained is made when the security group is created and cannot be changed retroactively without rebuilding the group and reattaching it to all relevant policies.

How do I find which roles are currently assigned to a position in Workday?

Navigate to the position record and use the Security tab, or use the Maintain Role Assignment for Position task filtered to the relevant position. For a broader view across multiple positions, the Security Group Membership report allows you to see all positions assigned to a given security group. The View Workday Account report is useful for seeing all security groups a specific worker belongs to, which indirectly shows you the position-level roles they are currently deriving access from.

Can a role be assigned to an unfilled position?

Yes. Role assignments on positions persist regardless of whether the position is currently filled. An unfilled position can hold role assignments, and those assignments will take effect immediately when the position is staffed. This is the correct approach for maintaining security configuration continuity across staffing changes. It is also how organisations ensure that the first day a new hire is onboarded into a position, their access is correct without any manual intervention by an administrator.

What is the risk of assigning a security role directly to a worker rather than to their position?

Worker-level role assignments do not follow position logic. They persist when the worker transfers to a new position, when they go on leave, and when they terminate – at least until the termination event is processed, and sometimes beyond it depending on how the termination is configured. This creates access that outlasts its intended context. In an audit context, a worker holding roles that do not correspond to their current position is a finding that requires explanation and remediation. In organisations with high internal mobility, worker-level assignments accumulate quickly and become difficult to track. The correct practice is to assign roles to positions and manage exceptions through the Assign Roles task with defined effective dates.

How does Workday handle Separation of Duties conflicts when assigning roles to positions?

Workday evaluates SoD rules at the point of role assignment and can surface conflicts when a proposed assignment would combine with existing assignments to create a defined SoD violation. The system does not block the assignment automatically in most configurations – it flags the conflict and requires an administrator to acknowledge it or take action. The SoD rule configuration determines which combinations of roles or permissions constitute a conflict. Because Workday surfaces conflicts at the assignment stage rather than enforcing a hard block, the responsibility for acting on the warning sits with the administrator. This means SoD governance requires human process controls alongside the system configuration. Running the Security Audit report on a defined schedule is the mechanism for identifying SoD exposure that has accumulated since the last review.