How to Use (Free) Atlassian Service Accounts

[#1]

As Atlassian Cloud Orgs grow, so does the web of automations, scripts, and third-party integrations that maintain everything running. But let's be honest, how many of us still use a quick, available but paid "dummy user" account, or worse, a real admin's personal API token to power an external integration?

We’ve all been there: a project or product admin leaves the company, their account is deactivated, and suddenly five critical business automations or AI integrations break because their token went dark. Thankfully, there is a much cleaner, native way to handle this in Atlassian Cloud: Service Accounts.

What Exactly is an Atlassian Service Account?

A service account is an identity designed to represent a tool, integration, or automation rather than a person. Instead of hacking together a workaround, you can use these dedicated accounts for:

• Global Automation & Scripts: Moving away from human-tied API tokens.
• AI & Third-Party Apps: Connecting external LLMs or BI tools securely.
• Scheduled Jobs: Making sure your cron jobs and data syncs have uninterrupted access.

As admins, we constantly fight to keep our user tier counts optimized. Here is the big win: Service accounts do not count towards your user tier limit. Instead of burning a paid license on a machine, Atlassian gives us native scalability. Every organization gets 5 free service accounts out of the box. If your organization uses Atlassian Guard Standard, that limit increases to 250 service accounts.

How to create an Atlassian Service Account?

• Log in to Atlassian Administration (https://admin.atlassian.com) and select your organization.
• In the left sidebar, click on Directory and then select Service accounts.
  
  
  
  
• Click the Create a service account button in the top right corner or the center.
• Name the account and add an optional description so other admins know what integration it belongs to.
  
  
  
  
• Click Create. Once the account is created, you can generate its OAuth 2.0 or API token.

Why You Should Audit Your Org This Week

Decoupling human identities from system access isn't simply about saving budget: it is about operational peace of mind. The next time HR requests an offboarding, you shouldn't have to worry whether a critical AI tool or pipeline will crash or spend hours reviewing all configurations.

You want to learn more?

• You can learn in this Community Learning course more about Service Accounts, Managed and Unmanaged Accounts, and how to maintain users and their access in an organization here: https://community.atlassian.com/learning/course/maintain-users-and-their-access-in-an-organization
• The official Atlassian Support documentation about managing your service accounts is available here: https://support.atlassian.com/user-management/docs/manage-your-service-accounts/
• You can find my blog post here: https://legit.de/the-strategic-value-of-atlassian-service-accounts/

[Arkadiusz Wroblewski]

@Martin Runge 

Thank you for complex explanation. As we get closer to sunset at Data Center, the importance of overall Service Accounts will only increase.

[Alex Gay]

Hi 

Can those service accounts be managed from your internal scim like Okta?

Regards

Alex

[Rebekka Heilmann _viadee_]

Hi @Martin Runge

important topic and not yet used enough. A few things to note:

1) Service Accounts cannot be used as Rule Actor in Automations, only for Webrequests within

2) From a Governance perspective, external LLMs etc. should act with the User's permissions rather than Service Accounts so Permissions don't differ from access within Atlassian.

3) API Tokens for Service Accounts are only valid for a year and as an Org Admin we are not notified. So integrations still break. Using OAuth should help as those credentials don't expire.

You can check out my full guide (that I regularly update) starting with part 1 here: 
A Guide to Service Accounts in Atlassian Cloud - P... - Atlassian Community