4.2 Assigning Roles & Security Group Membership

Membership follows the group type

The three membership mechanisms from the framework chapter determine how you actually add someone:

This is the single most useful troubleshooting rule in Workday security. Changing membership never requires activation. Changing a policy always does. If you added someone to a group and nothing happened, the problem is not activation.

Assigning roles on organizations

Role-based security groups are populated by role assignments, and role assignments are made on organizations.

1. Navigate to the organization - a supervisory organization, cost center, company, region, location, or custom organization.
2. From its Related Actions, select Roles > Assign Roles.
3. Enter an effective date.
4. For each organization role, add the position or worker that will hold it.
5. Submit. The change may itself route through the Assign Roles business process depending on your configuration.

Because membership is derived, the moment the assignment is effective, every role-based security group built on that role picks up the new member, and every domain and business process security policy carrying that group applies to them. No activation step, no separate membership edit.

Effective dating

Role assignments are effective-dated. A future-dated assignment does not grant access until the date arrives, and back-dating affects how historical business process events are evaluated. When an approval step routes to a role, Workday resolves the role holder as of the relevant date - which is why an event initiated last month may route to the person who held the role last month.

Inheritance down the hierarchy

Role assignments cascade down organization hierarchies. A role assigned on a superior supervisory organization applies to its subordinate organizations unless a subordinate has its own assignment for that role, which overrides the inherited one for that branch.

   Global Modern Services ──── HR Partner: Logan McNeil
        │
        ├── Field Sales ─────── (no assignment → inherits Logan)
        │      │
        │      └── US East ──── HR Partner: Maria Chen   ← override
        │
        └── Technology ──────── (no assignment → inherits Logan)

Two consequences:

• Assign high, override low. Assigning a role once near the top of a hierarchy and overriding only where the business genuinely differs is far easier to maintain than assigning at every node.
• An unassigned role stalls a business process. If no assignment exists on the organization or anywhere above it, an approval step routed to that role has no assignee. Whenever an event is stuck with no one to action it, check role assignment before you suspect the definition.

Position-based versus worker-based assignment

You can assign an organization role to a position or to a worker.

For ongoing operational roles, assign to the position. This is why a large part of Workday security maintains itself: when someone moves into the HR Partner seat, they inherit the security that seat carries, and when they move out, they lose it.

The equivalent risk on the other side is user-based groups, which are manually assigned and follow the user. Nothing removes a user-based membership when someone changes jobs, so user-based groups need a periodic review that role-based groups do not.

Maintaining manually assigned groups

For user-based and integration system security groups:

1. Search for the security group by name.
2. From its Related Actions, select Security Group > Edit.
3. Add or remove users - workers for user-based groups, Integration System Users for integration system groups.
4. Save. No activation required, because you changed membership rather than a policy.

Creating a security group

When no delivered group fits, use the Create Security Group task: choose the type first (the choice is not editable afterwards in the same way), name the group, then configure the type-specific criteria - included groups for aggregation and intersection, the role for role-based, the job criteria for job-based, the baseline group and rule for rule-based.

Then add the new group to the security policies it needs, activate those policy changes, and test.

Verifying membership

Run View Security Groups for User against the person before and after a change. It is the fastest confirmation that a role assignment produced the membership you expected, and it is the first step of the access-troubleshooting method in the next section.

Verify in a nonproduction tenant with proxy. Membership reports tell you what Workday thinks; proxy tells you what the user actually sees. Both are worth checking, and proxy is available in any environment except Production.