System Access Requests

[Brandon Kofer]

Hi all,

Our IT Dept handles the intake of all system access requests via JSM, regardless of whether the apps are IT-managed. I would say 85% of our apps are managed by IT, but for those other 15%, we're communicating through other channels (ie: Email and Slack) to get access created. This obviously isn't very effective, and oftentimes, these communications get lost in the day-to-day, resulting in employees not getting the access that they need in a timely manner.

I am curious: does anyone have a similar situation that you overcame? I was thinking, maybe we need to have a project for each of those other departments that manage these systems (ie: Finance Systems, Billing Systems, etc). Maybe we just create a whole separate project for Access Requests with a mix of Admins from various departments as Agents. What I wouldn't want is to bring users from other departments into the IT Project as there are things that they shouldn't have visibility to. Appreciate any feedback.

[Amaresh Ray – Multiplier]

@Brandon Kofer  not sure if you were able to solve this challenge but this is a pretty common scenario!

Managing access requests for systems owned by different departments is a common pain point, especially when trying to maintain a single intake point through JSM while ensuring proper approvals and visibility.

I've seen a couple of successful approaches:

Option 1: Dedicated Access Request Project

Creating a dedicated JSM project specifically for access requests has worked well for many organizations. This approach offers several benefits:

• Centralizes all access requests in one place
• Allows you to add admins from various departments as agents
• Keeps access workflows separate from other IT service requests
• Provides clear visibility into pending access requests across all systems

The workflows can be configured to automatically route requests to the appropriate department admins based on the system being requested.

Option 2: Access Request Catalog with Automated Routing

Another approach is to create a specialized access request catalog within your JSM portal and utilize automation to handle the routing and approvals.

Multiplier is an app that can help with this. (Disclaimer: I'm one of the founders). It connects to your identity provider (Azure AD, Okta, etc.) and provides:

• A self-service app catalog embedded in your JSM portal
• Automated routing to the appropriate approvers based on the application
• Automatic provisioning after approval for connected systems
• Time-based access 
• Comprehensive audit logs for compliance

Even for systems not connected to your IdP, Multiplier can route approval requests to the appropriate system owners and create tickets for manual provisioning.

Hope this helps! 

[Fernando Eugênio da Silva]

Hey @Brandon Kofer 

This is a completely valid concern. Generally, other teams end up creating other projects for these other areas so as not to popularize a project that is already fully operational.

If your concern is access to IT team issues that these areas should not have access to, know that you can meet this need using Issue Security. With Issue Security, you can have a Security Level for IT, Finance, HR and any other area within your single project, simply assigning the Security Level according to the type of associated ticket.

The Security Level guarantees visibility completely limited to only people who are part of the applied scheme, for other people, they will not be able to see any information that is in an issue at a different security level than their permission.

Please, take a few minutes to read about this subject here: Create security levels for issues | Jira Service Management Cloud | Atlassian Support

But if you choose to create separate projects, know that this is not completely unrealistic either. Some teams actually continue to create separate projects for other non-IT areas and that's okay too, as long as you can organize and centralize your processes.

Kind Regards,

Fernando