Best pattern for partner/reseller hierarchy in JSM Cloud using Organizations and Assets?

[Yousif Hassan]

Hi everyone,

I’m looking for advice from anyone who has implemented a partner, reseller, distributor, or multi-tenant support model in Jira Service Management Cloud Premium.

The hierarchy we need to support is conceptually like this:

Distributor
→ Reseller
→ Sub-reseller
→ End customer
→ Apps/Services

A few examples:

- A reseller may raise support requests for their own end customers.
- A distributor may have multiple resellers underneath them.
- A distributor may sometimes raise a request on behalf of one of their resellers or downstream customers.
- A reseller may need to see requests relating to their own customers.
- End customers generally do not log into the portal or raise requests themselves.

We are trying to solve two connected problems.

First, request visibility:
The right partner/reseller/distributor users need to see the right requests in the JSM portal.

Second, dynamic portal fields:
When a user raises a request, the form should only show customers, sites/groups, and services relevant to that user.

For example:

- A reseller logs in.
- The Customer field only shows that reseller’s customers.
- Once a customer is selected, the Apps/Services field only shows that customer’s  Apps/Services
- Once a Apps is selected, the Service field only shows services for that site/group.

The available values are not static. They are maintained in an external source system and can change over time.

The solution pattern we are considering is:

- Use JSM Organisations to control request visibility. 
- Use Assets to model the partner/reseller/customer/site/service hierarchy.
- Use Assets object references to represent relationships between those records.
- Use Assets fields on JSM request forms for the dynamic dropdowns.
- Use AQL filtering so users only see the Assets records relevant to them.
- Provision/sync users, Organizations, group membership, and Assets records from the external system via API.

This seems like the most native JSM Cloud Premium approach, but I want to sanity-check it before we go too far.

The part I’m unsure about is that JSM Organisations appear to be flat. There does not seem to be a native parent/child Organization hierarchy.

So if a distributor needs visibility across multiple resellers, our current thinking is that the distributor user may need to be added to multiple reseller Organisations. That seems workable, but it may create risk if the user needs to choose the correct Organization/request sharing option when submitting a request.

Questions:

1. Is this overall pattern correct: JSM Organisations for request visibility, and Assets/AQL for the hierarchy-driven portal fields?

2. Is Assets the right native tool for dynamic customer/site/service dropdowns where values depend on the logged-in user and are synced from an external system?

3. Are there better native alternatives to Assets for this kind of dynamic, per-user/per-partner dropdown filtering?

4. If JSM Organizations are flat, is adding users to multiple Organizations the right way to represent distributor/reseller visibility?

5. How have others handled the risk of users selecting the wrong Organization when they belong to more than one?

6. Is there a better native pattern for “raise request on behalf of downstream customer/reseller” scenarios?

7. At what point would this move beyond native JSM + Assets and require Forge, ScriptRunner, or another app?

I’m mainly looking for proven design patterns, lessons learned, or warnings from anyone who has built something similar.

Thanks in advance.