Rule Based Security Group

Workday has released a new type of security group called “Rule-Based Security Group” that uses the condition rule logic to determine the access membership. This condition logic can be used across various security groups. Earlier security groups were based on factors like role, organization, location based etc., For the need of a granular and flexible model, rule-based security group has been delivered. As of 2020R2 release, this group can be created by defining condition rule based on 23 fields in Worker business object such as Employee Types, Supervisory organization, Worker, Location, Job family, etc.., 

Let us understand with an example. First we need to create a security rule, with security rule type as membership rule, and business object as Worker.

• First, create a security rule.

by default the business object will be worker.

For this example we are considering security field as location address- country, as we are creating a rule for all employees in United States of America.

Next we must create a new security group with a base line security group, in this case we are using employee as self, and including the recently created security rule.

Now, we want to provide initiation access for BP change benefits for the employees in USA. So, we have made the changes in the initiation access of the BP.

Now, login as Hiroshi Yoshida, an employee of Japan country

Let’s try to check if this employee will be able to access the task Change Benefits or not. We can see that change benefits is not appearing, since the user does not have access.

While when we log in as Logan McNeil, we are able to access the task because Logan is an employee of USA country.

Rule based security groups provide greater flexibility to determine security membership. We can use only those delivered fields to create the condition rule. The flip side is calculated fields cannot be used to create the rule, and this is one area where we can expect new additions in the next releases.