Who Can Approve in JSM: Restricting and Mapping Approvers (Company-Managed vs Team-Managed)

[#1]

Disclosure: I build an approvals app for JSM. Nothing in this guide needs it — everything below is native configuration.

The complete guide gives the short version of this topic: don't let requesters populate the Approvers field directly. This is the long version — what Jira actually lets you lock down, where the walls are, and why the answer changes completely depending on whether your project is company-managed or team-managed. That difference is why a working recipe from one thread so often fails on someone else's site.

Where approvers come from (company-managed)

An approval step sits on a workflow status — Space settings → Workflows, pick the status, tick "Include approval step". Jira only offers it when the status has at least two outgoing transitions, one to become Approve and one Decline. The step itself holds no names. It reads them from a field: a user picker (multiple users) or a group picker (multiple groups). An ITSM space ships with two ready-made ones, Approvers and Approver groups, and change workflows can also pull approvers from the Affected services field.

One catch hides here, and it's the one that makes admins think their setup is broken: the source field must have Global context. Scope a group picker to just your project — a perfectly sensible instinct — and it silently disappears from the approval configuration. Atlassian tracked that as JSDCLOUD-10251 and closed it as a duplicate; the docs now carry the warning. The practical consequence: you cannot narrow an approver source per project through field context. The narrowing has to happen somewhere else, which is what the rest of this guide is about.

What you can restrict — and the wall everyone hits

Admins usually arrive at this topic wanting an allow-list: "only these eight people should ever appear in the picker." The approval configuration has no such setting. What it has is the reverse, an exclusion list. Under Exclude approvers from you pick fields — Assignee and Reporter are the shipped options — and anyone appearing in those fields cannot approve the request. This arrived in 2022 as the fix for JSDCLOUD-6249, the classic "requester approved their own request" problem.

Know exactly what it does, though: it blocks the decision, not the selection. An excluded person can still be placed in the Approvers field; they just can't act on it. There's a follow-up request (JSDCLOUD-13290) asking for the selection to be blocked too — closed for low engagement. And if you want to exclude broader sets, say all agents or a role, that was JSDCLOUD-11852, also closed. Fields on the request are the only exclusion source you get.

On the portal side there are two real controls:

• Take the choice away entirely. Per request type, the Approvers field supports "Use preset value and hide from portal" — the approvers are fixed by an admin, and customers never see the field. This is the strongest native restriction that exists.
• Control what customers can find. If you do leave an approver picker on the form, what a customer sees when they search is governed by the customer permission "Customers can search for other customers within their space or organizations". This one setting explains the perennial "my customers only see themselves in the approver field" threads — check it before assuming the field is broken. Customers can only ever add individual approvers, never groups.

One asymmetry to keep in mind: whatever you hide from the portal, agents can still add or remove approvers from the approvals panel while the step is active. Portal restriction is not desk restriction.

Mapping approvers automatically

Since there's no allow-list, the robust pattern is the one from the complete guide: put a controlled choice on the form (a select list of departments, request states, cost centres — anything but an open user picker), hide the real Approvers field from the portal, and let an Automation rule translate the choice into the authorised approver. The mapping then lives where only admins can touch it.

Two upgrades to that recipe:

1. Set approvers before the request reaches the approval status. The approval step reads its field at the moment the request enters the status. A rule that populates approvers on that same transition can lose the race and spawn the approval with nobody in it. Give the workflow a short triage status in front: the rule runs there, fills the field, then transitions into the approval status. Adding a "Re-fetch issue data" action after the edit, before the transition, keeps the rule working with current field values.
2. Per-requester managers can come from Assets. If you hold an Employee → Manager relationship in Assets, a Lookup objects action can resolve the reporter's manager and write them into the approver field — Atlassian's automation KBs document the pattern. The caveat they flag: reference the user attribute's accountId directly, not object keys, or the rule fails.

For self-approval specifically: combine the mapping with "Exclude approvers from". When the person-the-request-is-about lives in an Assets field rather than Reporter, mirror them into a plain user picker with automation (in the triage status, so the data is in place before the approval spawns) and point the exclusion at the mirror field. The approval step then enforces the rule itself, rather than you hoping nobody notices.

Team-managed is a different product here

Everything above assumed company-managed. Team-managed approvals are configured per request type — Space settings → Request types → pick one → Edit workflow → add APPROVAL — and the model genuinely differs, not just cosmetically:

	Company-managed	Team-managed
Configured in	Workflows (per status)	Request types (per request type's workflow)
Rights needed	Jira admin	Jira or space admin
Approver sources	User picker or group picker fields	User picker fields only — no groups (JSDCLOUD-11507, open)
The field itself	You create it, Global context required	Auto-created and linked by JSM
Who picks approvers	Implied by form + permissions	Explicit selector: customer, agent, or admin-preset
Exclude approvers from	Documented	Not documented

The explicit "Who chooses approvers?" selector is the part team-managed does better — admin-preset mode fills the approver field automatically when the step is reached, no automation needed. The rest is walls. Trying to attach an existing user-picker field as the approver source throws "Already exists. Try another name." — that's JSDCLOUD-13180, currently marked Ready for Development, and it's the exact error behind most "why can't I use my filtered picker" threads. And if you map approvers with automation, note that the Edit issue action doesn't support user-picker fields in team-managed projects — the KB workaround is writing the field through the Advanced/Additional fields JSON instead.

What you can't have

So you can stop searching: no partial quorum logic ("one approver from each of two groups") — the step counts approvals, it doesn't understand sets. No restricting where someone approves; email, portal and agent view all stay live (JSDCLOUD-17274). And no native delegation of approval rights while someone's away — that's JSDCLOUD-7867, sitting at 249 votes under Future Consideration since 2018.

Next in this series: group approvals — what the UI shows and hides when several people share one decision, and where the pending list actually lives. The complete guide links every episode as it lands.