A Guide to Service Accounts in Atlassian Cloud - Part 1: What they are (for)

[#1]

The (fairly new) Service accounts are non‑human Atlassian accounts you can use for scripts, integrations, and automations. BUT: they are not so simple as they sound like.

As an Org Admin, I keep being asked the same questions over and over. So I decided to put together a Q1/2026 guide (things are changing quickly). Shoutout to @Darryl Lee for reviewing!

To start of this guide and 3-part series, here are some serious Fun Facts about Service Accounts:

1. Only Organisation Admins can create Service Accounts
2. Service Accounts will get a generated account id based on their name
3. You cannot login to the UI with Service Accounts
4. Based on your subscription tier you’ll either get up to 5, 250 or 1000 Service Accounts
5. Service Accounts do not consume an App license
6. As of today, Service Accounts can be used with the Jira, Jira Service Management and Confluence API

Atlassian’s Documentation on the matter: https://support.atlassian.com/user-management/docs/understand-service-accounts/

---

What is a service account?

Many companies have created something like Service Accounts on their own, prior to this new feature - we call them Technical User for this article. But because new user accounts require email verification, this meant they would have to have a unique email address. Most importantly, the old style of Service Accounts would consume Atlassian Product/App licenses.

Service Accounts replace those “technical users”. They are managed entirely in Atlassian Admin and are not linked to a personal (or non-personal) corporate account.

You’d typically use one for:

• System‑to‑system communication
• Integrations and automations (CI/CD, sync jobs, reporting scripts)
• Bots that create/update Jira issues or Confluence pages

You want to use the REST API but not want your personal user associated with whatever you are doing? → Service Accounts

Also, if the task should keep running even if someone leaves your company, it’s a good candidate for a Service Account.

---

Use Cases for Technical Users & how to replace them

I regularly come across Technical Users being used in a variety of different scenarios. For some of them, Service Accounts are the answer. Others don’t need either and could be replaced by other Best Practices. Generally speaking, we want to get rid of the old license-consuming users in any case possible.

System	Use Case	“Technical User” Solution	Proposed Solution
Jira	Assign work item to a team	Use technical user as representative for a team and assign issue to that user	No Service Account needed Assign work item to a Team per Team field https://support.atlassian.com/platform-experiences/docs/what-is-an-atlassian-team/
Jira	Notify the whole team of new work	Set technical user (with group email) as default assignee and send notification to assignee on “Work item created event”	No Service Account needed A) Adjust the notification scheme and notify all role members on the “Work item created” event B) Use individual filter subscriptions to be notified of new work items in the Space C) use Automation to send Emails on specific events to shared email
Jira	Create work items via API (or other uses of Atlassian API)	Use a technical user so scripts do not use personal user credentials & work item history is comprehensive	Use Service Account instead
Jira	Automation rule actor	Use a technical user as the actor in Automation rules to keep the work item history comprehensive and mark automated actions accordingly	Use the “Automation for Jira” user as rule actor Note: Service Accounts cannot be used as rule actor yet
Jira	API calls to Atlassian API from within Automation rules	Use a technical user and a connected API key to call Atlassian’s API so rule does no use personal user credentials and automated actions are marked accordingly	Use Service Account instead Note: API calls to other systems credentials for that system
Confluence	Update pages/content via API (or other uses of Atlassian API)	Use a technical user so Scripts do not use personal user credentials & issue history is comprehensive	Use Service Account instead
Confluence	Automation rule actor	There is no Automation in Confluence on Data Center	Use your Personal Account for that Note: Unfortunately, there is no “Automation for Confluence” user and Service Accounts cannot be used as rule actor yet

---

Permissions + Scopes

Service Accounts must be granted App access and Permissions just like any other user. A service account’s effective permissions are the intersection of several layers:

1. App access (product level)
   • Does the service account have access to the Atlassian Ap at all?
   • Examples: Jira Software, Jira Service Management, Confluence.
2. Content access (space/project level)
   • Inside each app, the service account must be granted access just like a user.
   • Examples:
     • In Confluence: added to spaces with appropriate roles and permissions (e.g., “Can edit”).
     • In Jira: given “Users” Role in order to view/edit work items in specific spaces.
3. Credential scopes (API token / OAuth scope level)
   • Each credential (API token with scopes, or OAuth 2.0 client) defines what the credential is allowed to do.
   • Examples of scopes:
     • Jira: read:jira-work, write:jira-work, manage:jira-configuration
     • Confluence: read:page:confluence, write:page:confluence, delete:page:confluence

The service account can only perform an action if all three of these align: Product access AND content/permission access AND credential scope

If any layer is missing, the API call fails (often with a 401/403 type error).

Examples:

App Access: Jira
Space Access: Jira Space XYZ in Role “User” (gives Edit Permissions)
Credential scope: View Jira Work item (read:jira-work)
API Call: Edit Work item
❌ Will result in Error message, as Edit Permissions is not granted in API key scope.

App Access: Confluence
Space Access: Confluence Space XYZ in Role “User” (gives Edit Permissions)
Credential scope: Edit Confluence page (write:page:confluence)
API Call: Edit Confluence page in Space XYZ
✅ Will work as all levels are allowing access and edit permissions are set correctly

App Access: Confluence
Space Access: Confluence Space ABC in Role “User” (gives Edit Permissions)
Credential scope: Edit Confluence page (write:page:confluence)
API Call: Edit Confluence page in Space XYZ
❌ Will result in Error message, as Space access to Space XYZ is not granted

---

The email address that isn’t one

When you create a Service Account, Atlassian will generate an “email address” based on the name you gave the account:

Name: Test Service Account
Email: test-service-account-b1rvjssdkb@serviceaccount.atlassian.com

The Email is only relevant, if you are using Basic Authentication for API calls. It doesn’t have actual email features. You also cannot update it manually. My assumption is, that any user needs an email as that’s the primary key in Atlassian Cloud.

---

Next up: Setting up a Service Account

Come back for
Part 2: Setting up a Service Account
Part 3: Service Accounts in Practice

[Kristján Geir Mathiesen]

Takk so much for this great article, @Rebekka Heilmann _viadee_  And also my brother @Darryl Lee for reviewing.

[Alan Bruce]

Just starting to use our 5 available Service Accounts (only 5? really Atlassian). This article/series could not have come at a better time for me. Thank you!

[s_gridnevskii]

Am I right that if I create an alternative GUI for my employees and vote if anyone wants to use it I can create service accounts for them and they can use Jira/confluence using alternative UI without paying to atlassian?

[Rebekka Heilmann _viadee_]

@s_gridnevskii Short answer. NO.

several things.

1) Pretty sure this would violate Atlassian's license agreements. Service Accounts are not meant for replacing User Accounts

2) if you are not on Premium or Enterprise, you don't get enough Service Accounts to enable individual access so everyone would access through the same account which doesn't make sense at all

3) Sounds like you want Atlassian to be the Database and don't want any of the features. You cannot access all data through the API. The whole use case doesn't make sense. If you're that unhappy I'd recommend moving to a different tool completely.

[s_gridnevskii]

Rebekka Heilmann _viadee_, I was just guessing. In fact it is good to have service accounts for various automation rules. For the simple reason that if an employee retires all his rules will stop working instantly which will not happen if it is a service account that does all the work. I had this situation when previous Jira admin left company and it took me couple of days to reassign all rules he made to a service account.

As for 3 - some developers do not need whole Jira. They may add worklogs and close work items from console using curl. So what's the point of having accounts for them? Jira is mainly used by team leads and product managers to plan activities. After issue is assigned to a developer he does not need to go to Jira, he just reads description and does what is needed.

On one of my past workplaces we used alternative UI which was a portable GTK application that sat quietly in system tray. When issue was changed or a priority task was assigned to an employee he saw the icon blinking and could read what has changed and what he needs to do right now. It was very convenient - everyone knew his scope of work for every day.

[Rebekka Heilmann _viadee_]

Part 2

and

Part 3 

are out now!