Enabling Managed Accounts

Question

Greetings All,

We're working on enabling Managed Accounts in our Atlassian ecosystem and would like input from those who have already done so.

Any lessons learned you'd like to share

Anything you would have liked to know before you did it

Issues you ran into and resolution to them

Impact to end users

Thank You in advance,

Albert

Albert Chirighin · Answer

Hi @Prasanna Ravichandran

Thank You  , very helpful to prepare us for turning on managed accounts!

Albert Chirighin · Answer

Thank You @Arkadiusz Wroblewski , very helpful to prepare us for turning on managed accounts!

Arkadiusz Wroblewski · Answer

Hi @Albert Chirighin

Rather than repeating the usual “pilot + communicate” advice (which is true), here are the real-world gotchas and decisions that mattered most for us and actually drove the effort.

1) The biggest work is “identity hygiene,” not Atlassian clicks

Managed Accounts changes who owns identity for anyone on your claimed domains. The surprise for us was how many “special cases” lived behind that simple statement:

contractors using a company email,

shared mailboxes,

old accounts from mergers/acquisitions,

people who signed up years ago and forgot they did.

If you don’t map those categories up front, you end up firefighting exceptions during rollout.

2) Inventory integrations and service accounts before you enforce anything

This is the part we wish we’d started earlier. A lot of automation is quietly tied to accounts that look like normal users. Once you start enforcing SSO/MFA or tightening policies, those can break. What helped us:

list all API tokens / integrations and assign an owner for each

convert “shared mailbox” style accounts into dedicated technical accounts

decide whether each integration should use a token, OAuth/app auth, or be replaced

3) Decide your domain strategy early (and don’t claim more than you mean to manage)

We treated domain claiming like a boundary definition exercise:

Which domains are truly “internal”?

Which should remain unmanaged (especially anything external-facing)?

Do we need separate treatment for subsidiaries or regional domains?

This decision avoided accidental impact on users we didn’t intend to bring under corporate policies.

4) Admin resilience: plan a break-glass path

We set up a documented “break-glass” admin approach and tested it (sounds paranoid until the day your IdP misbehaves). It’s cheap insurance and makes everyone calmer during cutover.

5) User experience: the pain is mostly confusion, not downtime

Most users weren’t disrupted technically, the most common tickets were:

“Why does login look different?”

“Am I using my personal Atlassian account or work account?”

“I can’t access the right site anymore because I’m in the wrong session.”

Having a short “If you get stuck” guide (clear cookies/session steps, which login button to use, who to contact) reduced noise massively.

6) JSM note (if you have external portal users)

If you run Service Management portals, we were very careful not to accidentally push identity controls onto external customers. We only claimed domains we truly own and intend to manage, and we kept external requester domains out of scope.

If I had to boil it down:

Managed Accounts is successful when you treat it as identity governance + exception management, not a technical toggle. The “technical” steps are straightforward, the people and edge cases are what take time.