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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.