Single Catalog item to requests access to a table of applications

[sam28]

I have a question about how to manage large amounts of variables and UI policies on a single catalog item.  We have a growing application portfolio (as we move business units onto the Service Portal for request management) and we hold the list of applications on the 'applications' table.  

We have a single catalog item for 'Application Access Request' and then a reference field on the catalog item so that the requestor can select the application they are requesting access to.  Our legacy request system had hundreds of individual catalog items for' request access to application x' and 'request access to application y'  and we wanted to simplify this with the move to ServiceNow so we opted to create the single catalog item. 

The problem I am now facing is a growing list of variables and UI policies needed so that the requester can have the correct fields available to request access to a specific application ( for example: application x has access types of Read Only, Admin, Security Admin' and application Y has access types of 'Basic, Trader, Researcher, Admin' ) . Having the two different sets of access types means two sets of UI policies, two separate Select Box variables etc.. When you multiply that across an application table with hundreds of applications, this becomes a major issue.  

I am curious to hear how others have handled an access request type against a table of applications, where the user input can vary between applications that access is being requested for.  

[johnfeist]

Hi Sam,

I haven't had to deal with that scenario, yet.  I would approach it by putting the choices and options into a table, possibly sys_choice, so that they can be identified from a standard script.  In general, there is a limited number of types of options that you can expose for any given catalog item.  On that basis, I would define them generically.  From there I'd use a smaller set of catalog client scripts, AJAX and script includes to feed data labels, values, variable names, etc. so that the CCS can populate choices, hide/expose variables, etc. 

From there, your workflow can use metadata to understand what values to get from what fields.

Hope that helps.

:{)

Helpful and Correct tags are appreciated and help others to find information faster