nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to deal with an external partner organisation that works with multiple customer organisations

jack.verstappen

We are setting up CSM to be the portal for a number of custom organisations. In some of these organisation there is a partner organisation involved, who can raise requests for those organisations. For every request it needs to be clear which customer organisation it concerns, and what entitled product.

What are possible setups for dealing with this?

Accepted answers

All comments

Dan Breyen

Hi Jack, I have a similar situation. I'm assuming your partner org has the same staff reporting for the requests for the different customers. I have them make sure to notify us who the customer organization it. The partner staff are setup as customers for multiple organizations, and then I manually assign the organization to the request.

I was thinking about possibly making multiple Organizations "Partner-Customer", but that doesn't necessarily work when the partner staff can enter requests for multiple customers.

It took a little while, the organization will say the partner until I find out who the customer is, and then I will add or change the customer organization on the request appropriately.

Hope that makes sense.

Davit Mkrtchyan - Be On Time

Hi @jack_verstappen!

We're from the Be on Time team, and we've dealt with similar architectural challenges in Atlassian.

The struggle with partner organizations working across multiple customers is actually a fundamental issue. The biggest risk here isn't just the technical setup in CSM, but the cross-customer conflicts within the partner's team. When the same staff members are juggling requests from different clients, it's almost impossible to have a reliable capacity plan without a dedicated resource management layer.

Also, from a business perspective, you'll likely find that billing and cost attribution need to be strictly separated to avoid leaks and disputes.

If you're looking for a way to manage this more transparently, I suggest looking into a professional Resource Management approach. We've built tools specifically to handle this kind of complexity—making sure you know exactly who is working on what and for whom, without the guesswork.

We'd be happy to provide some free advice or a quick online consultation to help you map out a more sustainable workflow for your partner ecosystem. Feel free to reach out offline or drop a message here! 🚀

Gabriela - LeanZero

Hi @jack_verstappen, put the Entitlement field on the partner's request form. That's what carries which product a request is about, and through it which customer. Dan's multi-organisation membership is the prerequisite.

Create the entitlements at organisation level. On a customer who sits in an organisation, Create entitlement asks which of the two you mean, and the organisation option associates every customer in it. Then open Forms in your customer experience sidebar, drag Entitlement into the form fields and save. The partner picks the product at submit time, from the list they hold entitlements to.

Test it on one partner contact first. The whole thing rests on their picker spanning every organisation they belong to, and I haven't seen that documented either way. Also don't make the field required on a form that customers without entitlements use, they get no options and can't submit.

https://support.atlassian.com/customer-service-management/docs/about-products-and-entitlements/

Olha Yevdokymova_SaaSJet

Hi @jack_verstappen

Dan and Gabriela have outlined the two main native approaches.

You can add the partner’s users as customers in each customer organization they are authorized to represent. When raising a portal request, a customer who belongs to multiple organizations should be able to choose the relevant organization in the Share with field. Atlassian documents that this field displays the organizations the requester belongs to.

You can then add the Entitlement field to the request form. If entitlements are configured at the organization level, the partner can select the product or service related to the request from the entitlements available to them.

A native setup could therefore be:

Create a separate organization for every customer.
Add the relevant partner contacts to each customer organization they support.
Create product entitlements at the customer-organization level.
Add the Entitlement field to the portal form.
Ask the partner to select both the customer organization and entitled product when submitting.

I would test this carefully with one partner account first. A user belonging to several organizations should see those organizations in the Share with selector, but the Entitlement field may present products from across all entitlements available to that user. You therefore need to confirm that the customer and product combination remains unambiguous in your configuration.

Also review request visibility. Adding an organization to a request shares it with that organization’s members, so the partner should select only the customer organization concerned. You may also want the default sharing option set to No one, requiring the requester to select the organization deliberately instead of accidentally sharing the request with the wrong customer.

The manual alternative Dan described—letting the request initially show the partner organization and having an agent change it later—can work at low volume. However, it means the request may initially have incorrect customer context, entitlements, routing, SLA, and reporting.

Smart Forms for Jira, developed by my team, can provide one external form that the partner uses without requiring Jira access. Conditional logic can show only the products relevant to the selected customer organization, and form-to-issue mapping can write both values into Jira fields when the request is created. This gives agents an explicit customer–product combination on every request instead of relying only on the partner’s organization membership. Smart Forms supports external access, conditional logic, work items creation, attachments, and form-to-issue field mapping.

Birkan Yildiz _OBSS_

Hi @jack_verstappen

First, welcome to the Community!

Managing entitlements and tracking requests across multiple customer and partner organizations can be quite complex to report on using native Jira Service Management features alone. If you are open to using a Marketplace app, using a contract management app makes this kind of tracking and reporting very easy.
You might want to check out TicketBook - Service Time and Contract Management for Jira.

Here is how it can help with your specific setup:

You can define specific service contracts for each customer organization to automatically track their entitled products, ticket quotas, and service hours.

You can show these contract reports and remaining quotas directly to your agents in the Jira issue view, and display usage to your customers and partners right in the JSM Customer Portal.

You can find TicketBook - Service Time and Contract Management for Jira on the Atlassian Marketplace.

Full disclosure: I'm on the team that makes TicketBook. Hope this helps you set up a transparent portal for your customers!

Best,
Birkan

jack.verstappen

Been there, done that ... didn't like it ... The issue I have with this is that if 2 customers have an entitlement for the same product, the entitlement (dropdown) field shows twice the same product. If Atlassian would modify it with something like "{{product}} (for {{organisation}})", the user would actually be able to choose the right organisation by choosing the right entitlement.

Currently there is another "data isolation" issue with this. In multiple place it will show the list of tickets created by anyone belonging to the organisation.. and in case a customer belongs to multiple organisation, and created tickets for multiple organisation, they will show up for one specific organisation, i.e. including tickets that got created for another organisation.

Apparently there is something cooking at Atlassian, namely https://www.atlassian.com/roadmap/cloud/create-organizational-structure-to-enforce-data-boundaries?search=Unit&p=7a6ee076-60 but I have no certainty on delivery

jack.verstappen

Thanks for the suggestion, but I'm against investing in marketplace apps for functionality that Atlassian should cover correctly themselves.

Apparently there is something moving in this area, like https://www.atlassian.com/roadmap/cloud/create-organizational-structure-to-enforce-data-boundaries?search=Unit&p=7a6ee076-60

jack.verstappen

Unfortunately the Share with field only works with JSM, not CSM. And AFAIK, entitlements is something specific for CSM not JSM, as for entitlement you need the concept of products, and I believe it is only available when using CSM. Also, entitlements show up double if it concerns multiple organisation being entitled to the same product.

I agree with the mentioning of what the downside is of the manual alternative that Dan described.

As mentioned on another thread, I'm against investing in marketplace apps for functionality that Atlassian should cover correctly themselves.