Implementation of Access request

[Ankit28]

I need to work on a way for users to request access to ServiceNow itself. We give access to users by assigning roles to groups and making users members of those groups. We try not to give users roles directly because it makes management of roles more difficult. We also have customized the system to allow managers of groups to add/remove members themselves. They access this by going to "Groups I Manage" under the Support application. We need to provide a way in addition to this.

I'm thinking we should create a catalog item in the Service Catalog for people to request access. The catalog item should cause the user to select the group that they wish to be a member of. The list of available groups should be all active groups in ServiceNow which have a manager that is also active and where the group has a management type of "manual". Group management types are provided through a customization that we've made to the system. When a user requests to be part of a group, an approval task should be sent to the group's manager for approval. If approved, the user should automatically be added to the group. If rejected, the user should automatically be removed. The same thing should happen if the user requests to be removed from a group (offer option in same catalog item).

We could also think about allowing the user to request access to multiple groups at once. In this case it is possible that more than one manager would need to approve or that a single manager would be approving for access to multiple groups.

I'd keep it simple to start with and only allow a single group to be requested in a single submission.

Let me know what are the implementation steps(in detail)

[NeilH2]

Have a look at the SNC guru site

http://www.servicenowguru.com/system-ui/customizing-slushbucket/

I use the below to manage the list collectors
It will hide the query, field names, re size the list, and apply a default query.

function onLoad() {
 //Apply a default filter to the list
//Hide the list collector until we've set the filter
g_form.setDisplay('FIELDNAME', false);
//Wait for the list collector to be rendered
setTimeout(setMyFilter,1000);
}

function setMyFilter() {
//Find the filter elements
var fil = gel('ep');
//Hide the filter elements by un-commenting the following lines
fil.rows[0].style.display = 'none';
fil.rows[1].style.display = 'none';
fil.nextSibling.rows[0].style.display = 'none'; //Filter description text*/


//Reset the filter query
FIELDNAMEg_filter.reset();
var answer = 'QUERY HERE';
FIELDNAMEg_filter.setQuery(answer);
FIELDNAMEacRequest(null);
//Redisplay the list collector variable
//g_form.setDisplay('FIELDNAME', true);


var varName = 'FIELDNAME';
var height = '4'; //change height
var width = '250'; //change width
//Get the left and right bucket input elements
   var leftBucket = $(varName + '_select_0');
   var rightBucket = $(varName + '_select_1');
   if(height && g_form.getControl(varName)){
      //Adjust the bucket length (default is 18)
      leftBucket.size = height;
      rightBucket.size = height;
   }
   if(width && g_form.getControl(varName)){
      //Adjust the bucket width (default is 340)
      leftBucket.style.width = width;
      rightBucket.style.width = width;
 }
   //Fix the expanding item preview issue 
   $(varName + 'recordpreview').up('td').setAttribute('colSpan', '3');
   }

[jthowe64]

I am a SN noob trying to implement this process. I have started by trying to give managers of groups the access they need to add/remove members from the group. I have attempted to modify the ACL's to allow for this access, but have not been successful. Can you advise on how to implement this part of the process?

[Ankit28]

The form is right on. Now the workflow side of things! Right now it uses the workflow we have defined for all requests. I'd like to know about some ideas on a new custom workflow that we could use for this, but potentially useful for other things as well. A few points to keep in mind:
• Multiple groups can be selected. We would want to treat each group as a separate request item. Longer term — we would want to group the groups by group.manager and treat requests going to the same manager as a separate request item, but that's longer term only.
• We want the workflow to be useful for other purposes, so we'd want to be able to indicate who the individual approving is via a script. In this case, we would be indicating how to tell who the approver is, not actually who the approver is itself — which would be determined at run time. For example, we'd want to have the workflow accept a variable that specifies how to determine who the approver is. In this case, it would be the manager of the selected group. In another case (i.e. another catalog item entirely) for the same workflow, it might be the manager of the requestor. (I hope this is making sense)