Setting up a service desk for multiple departments

[Carlos Sarrate]

Hi!

I’m looking to set up a service desk that supports multiple departments (IT, Facilities, HR, etc.) and would really appreciate some guidance and best practices.

Ideally, each department would have its own queue with notifications routed to the appropriate group (e.g., it@, hr@). At the same time, I’d like users to experience a unified support portal. To start, I’d want them to be able to keyword search an issue and be directed to the correct category. Eventually, I’d love to incorporate an AI agent that could guide users to the appropriate Confluence page or ticket category across all departments.

Is something like this possible? And if so, what would be the best way to approach it?

Thanks so much!

[Josh]

Hi @Carlos Sarrate . Kudos to you for reaching out for guidance / best practices before embarking on the journey. Everything you've described is indeed possible.

I'd generally only recommend the single portal approach for smaller companies (e.g. < 250 FTEs). Once you start getting larger than that, it'd likely be helpful for you to have them in different portals (JSM projects) but still part of the same help center.

• This approach would give you a lot more flexibility around project / work item access, design, etc..
• Users could still perform a keyword search in the help center and be directed to the appropriate request types and Confluence knowledge base articles
• To simplify your life, you could start out the different portals using the same schemes (e.g. issue types, workflows, screens, etc.) and then you could always split them out down the line

There's been a lot of Atlassian- and vendor-created content related to having HR teams in JSM in the last couple years. I'm a bit more conservative in my approach to HR systems than what I've seen in those articles / talks. My general recommendation would be to tread with caution there.

• If you work at a global company or within a heavily regulated place like the EU, you'll definitely want to have conversations with your HR and Legal teams about what controls need to be in place.
• At a minimum, you'd want to have a bulletproof issue security scheme, limit agent access to the HR portal, limit org/site admins, avoid collecting any PHI/PHI wherever possible, and so on.

[Carlos Sarrate]

Thanks for the response!

Since we're a company with under 100 users, I agree that a single portal should work just fine. My main concern is how to properly segregate everything on the backend, especially considering the sensitivity of HR-related requests, as you mentioned.

What’s the best way to structure access, queues, and permissions so each department (IT, HR, Facilities, etc.) only sees their relevant tickets, while maintaining user privacy and compliance where needed?

Appreciate the insight!

[Josh]

@Carlos Sarrate - You'll want to set issue security for each team in your portal. The issue security will prevent users from being able to view any work items that are locked down, even if they navigate to another team's queue from the agent side (backend). Testing various scenarios will be key here to make sure you have everything setup properly from a security perspective.

[Marc - Devoteam]

Hi @Carlos Sarrate 

Suggestions from @Joseph Chung Yin and @Josh are alid, but with recent additions of Request Type Restriction, you can limit the request rype optons shown on the portal based on group and/or user.

And Issue Sceurtiy can be set on issues/work items to even have the agents see only the issues/work itesm they are allowed to see based on the set issue/work item security level.

[Joseph Chung Yin]

@Carlos Sarrate 

Welcome to the community.  I would recommend that you create multiple/manage JSM projects - one for each area.  This allows you the flexibility to customize each area customization as needed.  Most importantly, you will be able to control access to fit your needs (i.e. Only certain customers/agents can access the HR related project, tighter control on the queue management etc...)

The above path will still use the same portal UI (help center UI) for the customers.

If needed, you can also conduct issue links between the multiple projects for your internal agents as needed.

Hope this also helps.

Best, Joseph Chung Yin