ONE JSMportal for internal and external users

[Swathi Masetty]

We currently have several Jira Service Management portals (for IT, Helpdesk, DPSS, etc.), but my manager would like to consolidate everything into one single platform / portal.

I’d like to understand if and how the following setup is possible:

1. Single JSM project and portal, with automatic routing to the right people

   • Different people should handle different types of requests within the same JSM project.

   • For example:

     • If the request is related to issue 1, it should be automatically assigned to Person 1 by default.

     • If the request is related to issue 2, it should be automatically assigned to Person 2 by default.

   • The goal is to have one shared portal for everyone, but have tickets automatically assigned to the correct owner based on the request type or category, using full automation instead of multiple separate projects.

   • Is this possible to configure with Jira Service Management (using request types, fields, and automation rules) in a single project?

2. Different request types for external customers vs internal users in the same project

   • In this unified project, we expect around 6 request types in total.

   • 4 request types are customer-facing, used by external clients to raise tickets about our platform.

   • The other 3 request types are internal only, used for things like local development issues or internal technical work.

   • We want:

     • External clients/customers to see only the 4 customer-facing request types on the portal.

     • Internal company users to be able to see and use all relevant request types, including the 3 internal ones.

   • How can we configure the portal so that external users and internal employees see different sets of request types, while still using one single JSM project and one portal?

[Ajay _view26_ · Accepted solution]

Hi @Swathi Masetty 

Welcome to the community!

Yes, this is possible in Jira Service Management, but there are a few tradeoffs.

The normal pattern is:
- one service project / one portal
- multiple request types for the different kinds of requests
- portal groups to organize those request types for internal vs external users
- automation rules to route/assign the work based on request type, field values, component, organization, etc.

So for your example, a common setup would be:
- Request type A -> auto-assign to Person 1
- Request type B -> auto-assign to Person 2
- queues/views for each team or owner inside the same project

The main thing to think through carefully is permissions and visibility:
- internal and external users can coexist in one JSM project
- but if they should not see the same forms, knowledge base articles, or request history, you’ll need to design the request types/portal groups/permissions carefully

So short answer:
- yes, one shared portal with automatic routing is absolutely possible
- request types + portal groups + automation are the usual way to do it
- the harder part is usually access/visibility design, not the routing itself

[Swathi Masetty]

Hi Ajay,

Thanks for your reply. I have some more follow-up questions.

Here, Request A, Request B, etc., represent different support groups. Within each group, there can be multiple request types where users select the category of their issue and raise a ticket.

For example:

Request A refers to IT-related support . Within this, there can be multiple categories such as hardware issues, software issues, and so on. All IT-related tickets are initially assigned to Person A, who then reviews and reassigns them to the appropriate team member.

Request B refers to platform or product-related support. This can include categories like API issues, domain-related concerns, and other product-specific topics.

In this way, multiple request groups exist, each representing a different support function and containing its own set of categories.

Importantly, not all request groups should be visible to external users. For instance, Request B (product-related support) should be available to customers or clients, as it is relevant to them. However, Request A (internal IT support) should remain hidden from external users, since it is not applicable for them to raise such requests.

so with these kinds of requirements, is it still possible to create a JSM portal?

[Marc -Devoteam-]

Hi @Swathi Masetty 

Welcome to the community

This can certainly be done, you could set permissions to groups on request types, based on internal and external users.

Automation rules or even setting the assignee field on a request as hidden, with a default value can accommodate your requirement