Crossing The Line
During my consulting days I encountered an unique challenge while developing a custom application for an client. We had the traditional swim lane diagrams so each role was clearly identified and their tasks defined. I decided to use conditional layouts as the method of control for field level access.
A short time after the application was migrated to production the client’s requirements changed. Some individuals were identified as needing to occasionally fulfill more than one role. This change created an unique problem I had to solve.
Using conditional layouts to control field access based upon an user’s role is a common practice when private fields cannot be used. This method works well when a role is linear (i.e. stays within the swim lanes) throughout the life cycle of an record.
The challenge to this approach arises when a user’s role moves from linear(one dimensional) to expanded (multi-dimensional).
To solve this challenge you need the following items:
- A method to identify who will be granted the expanded access
- A method to identify when this should be allowed
- A method to grant the expanded access
My approach requires using two User/Groups list fields or Record Permission fields or an combination of both. Each field should be configured to only allow only one value [Max Selections set to 1]. Using the GETUSERS function you can retrieve the unique system assigned number for the account specified in a Record Permissions or User/Groups list field. If you then compare the values for the two fields and they match allow the extended access. If the values do not match, enforce the normal access for that role.
I created a helper field that checks to see if the accounts in the two fields match.
Role Overlap Helper:
- Values list field:
- Formula: IF(GETUSERS([Opened by]) = GETUSERS([Assigned To]),VALUEOF([Role Overlap Helper],"True"),VALUEOF([Role Overlap Helper],"False"))
Now you have the additional condition you can test in the rule used to trigger your conditional layout. In the Qualified Users/Groups section of your action, Select the Assigned To field and check the exclude box to remove the restrictions invoked by the conditional layout.
This approach worked for me and added another dimension of flexibility by allowing the individual to step outside their defined role when necessary.
- Community Thread
- Forum Thread
- RSA Archer
- RSA Archer Suite
- Tips and Tricks
Michael, This is a very good stuff. I've achieved the same for one client sometime back with a similar approach and nowadays this is becoming very common for a small team within a line of business/department where there's no SoD.
However thought to add another requirement into yours, where an user can be a member of both the groups/roles for e.g. Preparer and Reviewer but in the record they are either Preparer or Reviewer (Record Permission fields) at the same time.
If in ACL we use Groups in the Qualified Groups section, the DDEs will NOT work as desired where an user has both the groups (Preparer and Reviewer) assigned.
To overcome this problem, we've to use the Record Permission field in the Qualified Groups section. This will allow the DDEs to work as desired even if an user is a member of two separate roles/groups.