Separate Catalog Item for developer teams of Azure hosted applications
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hello All,
There is a requirement in our organization to build a separate Catalog Item for the Usage of Developer teams working on 'Application hosted on Azure'. However, we don have a separate form for the 'Application Access Request' for access to these applications.
Any ideas or similar catalog items created in other organizations, where there are two different forms for same application, one catering the general access and other catering the 'Developers work' is built? If yes, Please provide more thoughts.
Thanks for your time,
Vijaya
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi Vijaya,
I'd build this as a single catalog item, not two separate ones. Add a choice variable like Access Type = General / Developer, and let everything branch off that selection:
- Variables: Use two Variable Sets — one "General Access" set and one "Developer Access" set — and show/hide them with UI Policies based on Access Type. This keeps the form clean and avoids duplicating common fields (Application, Requested for, Justification). One tip: when you hide a mandatory variable, make its mandatory state conditional too, or the form will block submission on a hidden field.
- Application field: Make it a reference variable to your Azure business applications (CMDB or a custom table) so the one item scales to all apps instead of one item per app.
- Approvals: Handle this in a single Flow with a branch on Access Type. General → manager + app owner. Developer → manager + tech owner + cloud/platform security (and you can add a conditional approval when prod or elevated roles are involved). Two completely different approval chains live happily in one flow.
- Fulfillment: Same idea — branch the flow to the right assignment group / automation based on the selection.
This is more maintainable than two items and gives users one front door.
The one exception: if your security/audit team requires that general users never even see the developer path, or that developer (privileged) access be governed as a separate, certifiable entitlement — then split it into two items and use User Criteria to hide the Developer item from non-developers, since User Criteria works at the item level, not the variable level. Otherwise, the single-item approach is the way to go.
Please mark Helpful, if this helps
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi @Vijaya_Mnpram ,
- You can create a catalog item 'Application hosted on Azure' as select box (dropdown ) variable with choices.
- Also create 2 checkbox variables ( taking check box as choices are less for multi-select) named Request Type a. Application Access Request b. Developers work
- Note: If your Azure is having prod, non-prod tenant , you can take another dropdown or checkbox variable to select exact azure application of the environment
- For approval , if App owner or group details needs to pass to flow, create reference variable accordingly
Approval :
- Approval should be as per business requirement- Generally we got request for this kind of requirement : Direct manager approval -> App owner approval -> if business wants any kind of group approval
- Fulfillment would be performed based on Request Type check box selected , it would be routed that fulfillment group. It could be single or both and would be handled in Flow
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti