Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

Handling "mirroring" user access with another user

Mike49
Tera Contributor

Hi Community,

 

I'd like to know how others have developed the following use case:

 

A manager requests a user to have access to ServiceNow and wants the user's access to mirror another user on the team.  For each group, there needs to be an approval from the group's manager per Compliance.

 

The current process is that a manager selects a catalog item, selects an option called "Describe the user access" and in the textbox, says something like "This user joined my team and needs access like Joe Blow".

 

My current manager believes "mirroring" is not best practice. 

 

2 REPLIES 2

Brian Lancaster
Kilo Patron

We use groups to give access. The group provide the roles so all members of that group have the same roles. So I have 1 catalog item that automatically add/removes user from the group. It has 3 variables. 

Request type: dropdown with options Add user or Remove user

Group: reference to groups

User: reference to users

 

I also have a script include the based on the request type and group it will do the following.

If add user it will filter out all members of the group and only return users who are not members of the group to be selected in the users. It does the opposite if you want to remove users and only returns member of the group.

 

The workflow then requires Manger approval and group manager approval if they are not the same.

Hi Brian,

 

Appreciate the information. 

 

For multiple groups, do you create 1 REQ and multiple RITMs (1 RITM per each group) so then the group  manager can approve/reject the groups that the user can be added to?  My concern is that the same manager may get multiple approves since he/she manages multiple groups.

 

Currently when a user requests a SN Groups/Roles request, they have 3 options;

  • Provision user(s) to access group(s) - This one is self-explanatory.  Just add the user to the groups listed
  • *Describe access needed for the user(s) - This is our biggest pain point because they list the groups but then we need to reach out to the user's manager and get approval for compliance reasons.  
  • Request Access to DEV /  TEST - Self-explanatory

The *Describe access needed for the user(s) is the one we are trying to streamline.  Most of the requests with this choice say "Grant access identical to <user>".  So it would be nice to have a "Mirror access" option.

Thoughts?