Workday HCM security groups

I mentioned Workday security a while back.  Today, I'm thinking a lot about the concept of Workday 'security groups'.  In WD you assign users to groups.  The groups have various defined permissions.  If someone is in a group, they get those permissions.  A person can be a member of multiple groups.

 

A few key points:

1. Workday-delivered groups

Workday comes with some groups that get automatically assigned, based on WD's rules.  You cannot change/modify/delete etc. these groups.

Examples:  All workers, All contingent workers, All terminated people, All users, Employee as Self, Manager's Manager, etc.

2. Workday security groups get assigned a 'context'. 

This context is not changeable and it dictates what we'd consider to be 'row-level' security.  There are 3 types of context possible:

• Unconstrained - in such a group, the users have access to ALL data that the group allows. 
• Constrained - imagine a more limited group, a subset that is contrained--such as by organization.
• Mixed - a combination of the above two context.  A mixed group can be an 'intersection' or a subset of the two where they overlap, or an 'aggregation', so the two parts together, regardless of overlap.

It's a somewhat difficult concept to grasp by itself, but I found it starts to make a lot more sense once you look at the actual group definitions and configurations.

3. Security administration and on-going maintenance.

Excluding the system delivered ones, Workday groups can be manually assigned or auto-assigned.  More about this in a future post.  As well, user creation and termination of accounts can be automated.

Implementing Workday: future roles?

My colleagues on the other side of the pond have been going through onsite Workday HCM training, from a Workday trainer. It’s causing a lot of interesting discussions, as to ‘future roles and responsibilities’. For example, in our past world, IT administered PeopleSoft security. Then, due to some internal reorganisations, it went to HR. Now the topic is coming up again, and the discussions start: Who should adminster security in Workday? Of course, from the initial look at the software, potentially either group could do the work. It seems that Workday is built on a strong foundation of flexibility and is therefore hesitant to recommend which group should do the work. Upon discussing with other companies who have implemented it, the consensus seems to be: IT should do the role setup and administration (so the pages/permissions), and then HR should do the user administration (so assigning people to those roles). It seems like it would be a nice split from a delegation of duties perspective as well. However, not sure why wd does not recommend this as a ‘best practice’?