How to Group Jira Service Management Requests by Customer Organization
Jira Service Management does have a feature built for this, called the Organizations field. Create an organization, add the customer's users to it, and any request one of them files can be shared with the whole group, so a teammate at the same company sees it too. The catch is that an organization only works inside the service project it's been added to. If your account files requests against three different projects, hardware support, software support, and onboarding, you're looking at three separate customer lists, and nothing native rolls them into one view of "everything this account has ever asked for."
So the honest answer is partially, and only per project unless you do the linking yourself. The rest of this guide covers the actual setup, the step people miss that causes "no matches found" when they try to use it, and what to do once one account is spread across more than one project.
How the Organizations field actually works
An organization in JSM is created once, then customers get added to it as members. From there, an agent (or the customer themselves, if you allow it) can share any request with that organization, and everyone in it can see and comment on the shared request instead of each person filing their own copy.
Two things trip people up immediately, both confirmed on Atlassian's own community forum:
- Creating an organization isn't the same as making it usable. A thread from an admin who set up several organizations and then got "No Matches found" trying to populate the Organizations field on an issue got an accepted answer explaining that organizations have to be added to the specific service project too, via Customers > Organizations > Add organizations inside that project. Creating one at the account level doesn't automatically make it selectable on issues.
- There's no built-in list of your organizations. A separate thread asking for an easy way to generate a list of all customer organizations got an accepted answer that boiled down to contacting Atlassian Support for a CSV export, because there's no report for it in the product. One reply put it bluntly, there's no out-of-the-box tool that gives you that listing. If you want it yourself, you're looking at the REST API or a marketplace app.
Neither of those is a dealbreaker for a single project. They matter because the fix for the first one (add the organization to the project) has to be repeated, by hand, for every project that account might touch.
Where this holds up fine
If your JSM setup is one service project, or an account only ever talks to one team, Organizations does what you'd want. Set it up like this:
- Create the organization once, name it after the account.
- Add the organization to the project (the step above, easy to skip on a team-managed space).
- Add each known contact at that account as a member.
- Share incoming requests with the organization, or turn on the setting that shares a customer's requests with their organization automatically.
From that point, anyone in the account can see the shared requests, and an agent working the queue can filter by organization to pull up everything one company has open. That is a real, working "view requests by customer" inside that one project.
The multi-project problem
Most JSM instances aren't one project. A support org running hardware, software, and onboarding as separate service projects is normal, and a mid-size customer account usually touches more than one of them within a few months. Here's what breaks:
- The organization has to be added to each project separately, and it's easy to add it to two and forget the third.
- Filtering by organization only searches within the project you're standing in. There's no cross-project "show me organization X" view built into the product.
- The membership list can drift between projects if someone updates it in one place and not the others.
You end up needing a person to know that "Garrow Foundries" exists as an organization in three different places, keep the membership consistent across all of them, and manually check each project's queue to answer "what has this account asked for lately."
How Reyna Castillo hit this at Millrace Systems
Reyna Castillo runs support ops at Millrace Systems, which sells sensor monitoring hardware and the software that reads it to manufacturing plants. Their JSM instance has three projects: Hardware Support, Software Support, and Onboarding, split because the queues need different SLAs and different agents.
Garrow Foundries came on as a customer in the spring. Their plant engineer filed two hardware tickets about a sensor calibration drift. A month later their ops manager filed a software ticket asking why the dashboard wasn't reflecting the same readings, and a separate onboarding request came in from someone setting up a second site. Four requests, one account, three projects, three different people filing them.
Reyna put it this way in a note to her team lead afterward.
"I only found out the software ticket and the calibration tickets were the same account because I recognized the plant name in the description. If Garrow's ops manager had filed under a different email domain I'd have missed it completely."
Reyna had, in fact, added Garrow Foundries as an organization in Hardware Support months earlier. She hadn't added it to Software Support or Onboarding, because nothing prompted her to until a request from that account showed up there. Once she noticed the pattern, fixing it meant opening each project's Customers settings, adding the organization, and re-adding the same three contacts three times.
The ceiling of the manual approach
Reyna's fix works for Garrow Foundries. It does not scale past a handful of accounts that happen to cross projects, because:
- Nothing tells you an account has crossed a project boundary. You find out by recognizing a name or a domain in a request you're already reading, the same way Reyna did.
- Keeping membership in sync across projects is a manual, repeatable chore with no reminder built in when it goes stale.
- A "give me every request from this account" answer still means opening three project queues and reading each one, even after the organization is set up correctly everywhere.
That's the ceiling of what the manual approach gets you. Correct configuration produces a filterable list inside each project, not a merged one across all of them, and the setup itself has no cross-project awareness.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionOnce more than a handful of accounts start crossing project lines, keeping Organizations current everywhere turns into a manual chore with no end date. We built Modem to close that gap. It watches every JSM project you connect and matches requesters to companies automatically from their email domain, instead of relying on an Organizations field that has to be configured project by project, then rolls up every request tied to that company, hardware, software, and onboarding alike, into one account view with the original quotes and reporters attached. We build Modem, so weigh that recommendation accordingly. Setup and what gets captured is on the Jira Service Management integration page.
If Garrow's four requests are the kind of pattern you want surfaced automatically instead of noticed by accident, two related guides are worth reading next. How to see which customers are affected by a Jira bug covers the adjacent problem of counting impact rather than counting projects, and the wider field of JSM feedback tools compares options beyond Modem if you want to see the landscape first.
The audit worth running this week
Pick your two or three biggest accounts by request volume, and check whether their organization exists in every project they've actually filed against, not just the first one you set it up in. That single audit usually surfaces the same gap Reyna found, an account you thought was fully tracked, missing from one project's Customers list the whole time.
