REST API 400 Error: "Local Service Desk users cannot be added to groups" when adding user to group

Phil Steinbach

Hi everyone,

I am using Power Automate to add users to an Atlassian group via the Jira Cloud REST API:

• Endpoint: https://exte-wipp.atlassian.net/rest/api/3/group/user?groupname
• Headers: Authorization (Basic Auth / API Token) / Content-Type: application/json
• Payload: {"accountID": "(accountid)"}

For some users, this request works without issues. However, for specific users, it fails with HTTP status 400 and the error message:

"Lokale Servicedesk-Benutzer können nicht zu Gruppen hinzugefügt werden" (Local Service Desk users cannot be added to groups)

Observations:

1. In Jira / Atlassian Administration, the affected users appear to have the exact same roles, licenses, and product access as the working users.
2. The user type is not visibly different in the UI.

Questions:

• What technically defines a "local Service Desk user" in Jira Cloud?
• Is this related to portal-only customer accounts vs. managed Atlassian accounts (Atlassian Access / Cloud ID)?
• How can this be resolved so that these users can be added to standard groups via API?

Thanks for your help!

Josh

Hi Phil, to your first question: "local Service Desk user" is Jira's internal name for a portal-only customer account, the kind JSM creates for someone who raises a request by email or through the portal. Dirk is right that such an account can't hold a licence. The catch is that the same person can have two accounts with the same email: their licensed Atlassian account and an older portal-only customer account. In the admin UI you only see the licensed one, so everything looks identical. But if your flow looks up the accountId by email, it can pick up the customer account, and that's the ID being sent to /group/user.

You can confirm it quickly for one failing user:

• Call GET /rest/api/3/user?accountId=<the ID your flow sent> and look at accountType. A working user returns "atlassian". A portal-only account returns "customer", and its ID usually starts with qm:.
• Compare that with the accountId in the URL when you open the same person under admin.atlassian.com > Directory > Users. That's the one you want.

To fix the flow:

• If Power Automate resolves users with /rest/api/3/user/search?query=<email>, don't take the first result. Filter the results to accountType == "atlassian".
• Better still, store the Atlassian accountId from your source system or from the admin directory and pass that instead of searching by email.

For the root cause, Atlassian has a KB on exactly this (Duplicate account issues in JSM Cloud). The clean fix is to migrate the portal-only customer to the Atlassian account: in Atlassian Administration go to Products > your site > Jira Service Management > Portal-only customers, find the email, and choose Migrate to Atlassian account (steps). Their request history moves across and the duplicate goes away, so an email lookup can't return the wrong ID anymore.

Your latest reply fits this: adding the user manually works and the group is a plain local group, so the group isn't the problem. What differs between the UI and your flow is the accountId being sent.