Architecture advice: Single JSM Portal for multiple physical locations with strict Asset isolation?

Question

Hi community,

I am designing an IT Service Management solution with many different physical locations. I am hitting a wall regarding data isolation in Jira Assets and would love to hear your architectural advice.

The Hard Requirements:

Single Customer Portal: All end-users must go to one unified JSM portal to report issues.

Strict Data Isolation for End-users: When an end-user raises a request, they must ONLY see the IT assets belonging to their specific location.

Strict Data Isolation for IT Agents: IT Agents at Location A must NOT be able to see assets, users, or tickets from Location B.

The Architecture Challenge:
Because Jira Assets currently lacks Object-level or Attribute-level security, I am caught between two suboptimal paths:

Path A: 1 Global Schema + AQL. Pros: Clean backend, easy to maintain. We can use AQL on the portal to filter assets by the reporter's location.
Cons: Fails the Agent isolation requirement. If an Agent gets Object Schema User permission, they can see the entire global inventory of all locations.

Path B: 17 Independent Schemas

Pros: Absolute data isolation. Agents only get permissions for their specific schema.

Cons: Admin nightmare. We would need many Custom Fields (mapping to 17 schemas). To keep the "Single Portal" experience, we'd have to rely heavily on JSM

My Questions:

Has anyone successfully implemented strict Agent-level data isolation across multiple sites without creating a massive maintenance burden (like Path B) ?

Would a model (1 main portal project syncing to 17 backend projects via Automation) be overkill here?

Appreciate any insights or war stories you can share!

Marc -Devoteam- · Answer

Hi @Bảo Phạm Gia

"Managing assets by each specific location is absolutely necessary for this client. The stakeholders require strict data isolation to ensure that one campus cannot view or interfere with another campus's financial and asset inventory"

Has this topic nee raised with the CIO or Security and Riks management of this client?

As I think these a the responsible stakeholders for this decision, are they the stakehodlers you metion?

There is no middle ground to find if this strict separation is needed, as Assets offer no option to share information if this can't be access (seen) by others.

Bảo Phạm Gia · Answer

Hi @Arkadiusz Wroblewski  @Marc -Devoteam-

Thank you both for your valuable insights! You perfectly highlighted the architectural dilemma we are facing.

To answer Marc's question regarding the requirement: Managing assets by each specific location is absolutely necessary for this client. The stakeholders require strict data isolation to ensure that one campus cannot view or interfere with another campus's financial and asset inventory

However, I completely agree with both of you on the technical side. If we fully separate them (e.g., creating 17 independent schemas) to meet this strict isolation rule, the deployment and ongoing maintenance will become a massive headache.

Given this conflict between "strict business data isolation" and "system maintainability", what would be the most optimal architectural approach in your experience?

Is there a "middle-ground" solution you have successfully implemented? or a specific automation pattern that makes maintaining separate boundaries less painful?

I would really appreciate any ideas or best practices you could share on how to optimally balance these two extremes!

Arkadiusz Wroblewski · Answer

Hello @Bảo Phạm Gia

I think @Marc -Devoteam-  is right on the important part here.

A shared global Assets schema may look cleaner at first, but it is still a shared backend. That means you are starting from a model built around centralization and then trying to add isolation afterwards. For reporting, routing, and general administration, that can work. For strict separation between locations, it is a much weaker foundation.

The key issue is that AQL helps with filtering and visibility in specific contexts, but it is not the same as a real security boundary. If agents from one location must not see assets from another location, then that separation should exist in the architecture itself, not only in how data is filtered on screens or forms.

That is why I would be careful with the “one global schema” approach. It can easily feel fine during design, but later become difficult to defend once permission, audit, or compliance questions come up. At that point, “we filter what they should see” is simply not as strong as “they are separated by design”.

So from that perspective, separate backend boundaries do not feel like overengineering to me. They feel like the more reliable design choice when strict isolation is one of the actual requirements.

If the requirement were only convenience, common processes, and easier administration, then a shared model would be easier to justify. But once hard separation is part of the goal, I would rather design around that from the beginning than try to retrofit it later.