System Access/Access Request Forms

Ryan_Murphy

Wondering how everyone does their system access requests. Do you split up new user onboarding access, termination, current user access, etc.? How about hardware requests for new users and current users? Just wondering how everyone does their access requests as this is something we have put off due to its complexity. 

Currently, we use a form that the user fills out that includes check boxes for (new hire, existing, consultant), (laptop, docking station, desktop, monitor, desk phone, mobile phone), (location/contact info), (network/file access), (application access - mainframe, unix and windows). It's a fairly complex form that is too often filled out incorrectly and we want to simplify it without losing out on the important information, but also make the process of this easy and understandable on the end users. Is it recommended to split all of these fields up into different request offerings, or perhaps have one request offering using an advanced form?

Just looking for thoughts and ideas of others to incorporate into our process and workflows.

Ryan_Murphy

Bump

Davin_Clouthier

We initially tackled this before the AO was available so we had a New User, Application Access, Hardware Request, Transfer, Remove Buttons. Each with there own workflows built in. We just recently upgraded to portal v7 and are scoping out our project to bring all of these together in one multipage AO and give access outside of IT to take some load off of the frontline. Our initial setup was also pure powershell the 2nd time around we are mixing powershell with orchestrator too simplify managing and updating of the entire flow of things.

Just how we are tackling it, looking forward to hearing how others have done this!

Ryan_Murphy

My idea was also to use a multipage AO, however there is a major issue that I cant seem to deviate from.

The primary issue being if my template behind the AO was built to send tickets to multiple different support groups for different work to be performed, but the requestor didn't need work to be performed by a specific support group, they'd still get a ticket. How would I avoid this? So for example, if all the user needed was mainframe access (I know...) from whom we'll call Mainframe SG, the team who grants access to shared drives which we'll call SysAdmin SG would still get a ticket assigned to them even if there is no work to be performed. 

You said you originally had all of your different requests with different buttons. That would make the most sense to me from a ticket distribution standpoint, but not from an ease of use for end users standpoint. I'm looking for the best way to have the end user fill out a form for what they need and then tickets are sent to the right queues, like with MA's and RA's so that certain work isn't able to be performed until certain work is done, etc. But I'm also trying to avoid the "primary issue" I described above.

Davin_Clouthier

Well how I avoided this in our first versions of the buttons is have a MA at the start called automation assigned to my automation distribution group, and when the groups wern't required when they were still in a pending state the tasks would be skipped before ever hitting there team. So they didn't get work if they didn't have any work. Atleast that's how we approached the issue

To explain this a little bit better, we setup a workflow to be triggered on the static ticket naming scheme we picked and condition if Automation task or automation task stage 2 were in progress. , and attached powershell to the workflow using the auditing tool. Checked all the user entries and skipped the tasks that would not be required then completed the automation task so the first parallel activity would kick in. I'm sure there is a better way too approach this but I haven't found or figured one out yet.

Edit: Example our Transfer Workflow -

Ryan_Murphy

Thank you for this. I have one question. Certain tasks are in a Skipped state. Are these manually skipped or is there automation behind the AO where if the user doesn't need specific access, the MA is skipped?

Davin_Clouthier

Automation behind the AO based on the users selections. So if they would check off that they needed a phone with the transfer for example the lync team would get a configuration MA, if not it would get skipped. All based on user input mostly. Currently its done with Service Manager Authoring Tool + Powershell, to create the management pack and conditions. But we are moving to orchestrator currently to move this to a runbook.

Ryan_Murphy

Gotcha. Thank you for this. This could help us greatly