Support for multiple portals per JSM project to better organize request types

[Michel Zbierski _SMA_]

Hi everyone,

I’d like to draw some attention to a feature request that could greatly improve how we structure and manage service portals in Jira Service Management Cloud:

👉 JSDCLOUD-15485 

The issue:
Currently, each JSM project can only have one customer portal, where all request types are displayed – grouped by request groups. While this might be sufficient for simple setups, it quickly becomes confusing in environments with many services and request types.

Our use case:
We manage multiple internal services in a single JSM project. Ideally, we’d like to create separate portals within that project, for example:

• One portal for Incidents

• Another portal for Service Requests

• Possibly more, focused on specific services or user groups

Request groups unfortunately don’t provide enough separation, as everything ends up in one large portal – making it hard for users to find what they need.

What we’re asking for:
The ability to define multiple portals per JSM project, each with its own set of assigned request types.
This would allow us to:

• Improve user experience by offering focused entry points

• Avoid duplication of request types across multiple projects

• Keep project-level features (like SLAs, automation, Assets) centralized and consistent

If this resonates with your use case too, we’d really appreciate it if you could vote for or comment on the ticket to help raise visibility

JSDCLOUD-15485

Thanks for your support!
Michel

[Dwight Holman]

Can you unpack more why do these need to be in a single JSM project? You mentioned two reasons in your post:

1. Avoid duplication of request types across multiple projects.
2. Keep project-level features (like SLAs, automation, assets) centralized and consistent

Yes these make sense, but they do not seem to be blockers.

IMHO if the requests are sufficiently different (e.g. for a different product or service area) or are handled by different people, then a separate project makes sense.

I agree JSM does not provide enough flexibility in how the portal appears to a user/customer.

There is a backlog item which seems similar to what you are asking:

JSDCLOUD-13397 - Configuring different URLs for JSM portals within the same Help Center

[Michel Zbierski _SMA_]

Hey

Thanks a lot for the thoughtful reply!

You're right — if requests are completely independent (different teams, services, workflows), splitting across multiple JSM projects is definitely the cleanest approach.

However, in our case (and likely in many larger organizations), things aren’t quite so black and white. We’re managing multiple (20+) closely related internal services within the same team or department. While the services differ, they share:

- Same Service-Dependend Queues (Help-Desk Agents must either jump betweend projects)

- Common SLAs (e.g. internal support targets across all services)

- Shared automation rules (e.g. common routing or escalation logic)

- Same Asset schema (referencing the same CMDB)

- Same permission model

- And ideally, reusable request types (e.g. "Request access", "Report incident", "General inquiry")

Splitting these across multiple projects would create a lot of duplication and overhead for us — especially in maintenance and reporting even if we use company-managed projects. That’s why keeping them in one JSM project with multiple tailored portals would be a big improvement from both the admin and user perspective.

I also appreciate you linking to JSDCLOUD-13397 — it’s definitely related, though I think what I’m describing is more like an evolution of that idea: being able to configure separate “views” or sub-portals within one project, each showing only a subset of request types.