If you run Atlassian Cloud at scale, you’ve probably asked this at least once:
“Is the user data actually up to date?”
Because when it isn’t, and you act on stale data, things go sideways fast. The classic scenario: you think a group change didn’t apply, you “just fix it” with a bulk action, and suddenly you’ve deactivated the wrong users or removed access from an entire department right before a release.
In this post, we’ll break down how sync and data freshness work in User Manager, why it uses a mirrored data view, and the practical steps to take before running automations or bulk operations.
The problem: “Freshness” isn’t one thing
User data doesn’t live in one place. It travels through a chain of systems, and each step can introduce delay.
That’s why “the data is wrong” often really means:
The data is right… but somewhere else.
So instead of guessing, you need a simple model for where the delay is happening.
The mental model: 3 layers of user data
Think of user identity and access flowing through three layers, each syncing on its own schedule:
1) Your Identity Provider (IDP)
Examples: Okta, Microsoft Entra ID, Google Workspace
This is the source of truth for identity, group membership, and lifecycle status.
2) Your Atlassian Organization (Atlassian Cloud)
Atlassian receives user and group updates through SCIM provisioning (SCIM 2.0).
SCIM can:
create users automatically
update attributes (name/email)
manage group membership
deactivate users when disabled in the IDP
3) User Manager’s mirrored view (User Manager database)
User Manager maintains its own synchronized “picture” of users/groups/product access so operations remain reliable at enterprise scale.
Key takeaway:
When something looks stale, ask: Which layer is behind?
Why User Manager uses a mirrored database
At enterprise scale, bulk operations can’t rely on a long chain of real-time API calls. When you’re working with hundreds or thousands of users, API-heavy operations can:
time out
fail partially
become inconsistent
be slower than expected
To avoid this, User Manager keeps a mirrored user management view in an Atlassian Forge SQL database (Atlassian-hosted storage for Forge apps).
This mirrored view is what makes:
bulk operations predictable
automated tasks reliable
results consistent even under load
The goal isn’t “sync more often”
It’s:
Use the right sync at the right time
…and understand what each sync guarantees.
Let’s walk through the sync types User Manager uses.
How sync works in User Manager (5 sync types)
1) Initial full sync (first-time baseline)
When you install User Manager, it performs a complete sync of:
users
groups
product access
across all connected sites.
This creates the initial baseline in the mirrored database.
2) Daily scheduled sync (nightly reconciliation)
In Settings → User data synchronization, admins can configure a daily full sync time slot.
This should be scheduled outside business hours to reduce “noise” while admins are actively changing access.
What it’s good for:
reconciling changes made directly in Atlassian
catching updates that arrived during the day from the IDP
keeping the mirror consistently aligned over time
Practical tip: Choose a quiet time—early morning or late evening.
3) Pre-operation sync (your safety net)
This one is easy to overlook—but it’s one of the most important.
Before bulk operations or automated tasks, User Manager performs a targeted sync of what matters most for that operation.
In human terms:
Before the app changes anything, it refreshes the relevant data so you don’t act on yesterday’s truth.
This is how you avoid running a bulk action on a list that was accurate yesterday—but not five minutes ago.
4) Manual sync (“Run sync” button)
This is the make-it-current-right-now tool.
Use it when:
you’re about to do something big
you need group membership changes reflected immediately
you suspect the mirror is behind and you want to refresh before proceeding
In Settings near the daily sync configuration, you’ll find a Run sync button. It kicks off synchronization and provides status/details.
A favorite way to describe it:
It’s like clearing the cache… except this time it actually works most of the time.
5) Post-operation sync (reconcile after changes)
After bulk operations or automated tasks, User Manager syncs changes back into its database so the mirror remains consistent with the real Atlassian state.
This matters because otherwise you’d run a bulk change and then immediately stare at outdated results—wondering if it worked.
Where most confusion comes from: SCIM + IDP delays
SCIM provisioning is powerful—but it’s also where people get tripped up.
Some IDPs push changes instantly. Others batch updates. Large directories take longer. Atlassian may apply updates quickly… or with a delay depending on volume and frequency.
So if you change something in your IDP and don’t see it in Atlassian yet, the delay is often in:
Layer 1 (IDP) or
Layer 2 (Atlassian org via SCIM)
– not in User Manager.
The troubleshooting sequence (stop guessing)
When someone says, “the data is wrong,” use this order:
Confirm the change exists in the IDP
(Is the user really in the group? Was the lifecycle change saved?)
Confirm it reached Atlassian via SCIM provisioning
(Did Atlassian receive and apply the update?)
If you need User Manager updated immediately, run a manual sync
(Bring the mirrored view current before you act.)
Follow this sequence and you isolate where time is being lost instead of guessing.
Data freshness checklist (before bulk ops or automation)
Before you run a bulk action or automation, run this pre-flight:
Where did the change originate?
IDP?
Or directly in Atlassian?
If it’s from the IDP, it must travel IDP → SCIM → Atlassian first
If timing matters, refresh right before the operation
rely on pre-operation sync
or run a manual sync if you want certainty
After the operation, expect reconciliation
the mirror updates so results match reality
Next steps (what to do today)
1) Set your daily sync outside business hours
Go to User Manager settings and choose a time slot when your org is quiet.
2) Do a “freshness pre-flight” before your next major bulk operation
Make a small test change (e.g., add a test user to a test group), verify it appears correctly, then proceed.
3) Add a team note: “When data looks wrong, identify the layer”
IDP → Atlassian org → User Manager mirror
That one habit can cut incident resolution time dramatically.
Final thought
Bulk operations and automation are powerful, but only when the data you’re acting on is trustworthy.
Once you understand the three-layer model and the five sync types, you stop guessing, and start running user management safely at scale.
And may your user data always be as fresh as the coffee you forgot on your desk this morning.
