Sync and Data Freshness

User Management maintains a local copy of your organization's user data in Forge SQL. This page explains how synchronization works, what triggers it, and how to plan around sync timing for large organizations.

How Sync Works

The app cannot query Atlassian's Organization API in real time for every page load or operation. Instead, it mirrors user, group, and product access data into its own Forge SQL database. Each sync cycle pulls the latest state from the Organization API and updates the local copy.

Sync Types

The app uses five sync types, each triggered by different conditions. These five sync types apply when Sync Mode is set to Daily (the default). Organizations using Continuous Sync via Atlassian Guard follow a different cadence - see Big Organization Sync Mode below.

Syncs Running Alongside Operations

A sync can be in progress while a bulk operation or automated task is running. This applies in both Daily and Continuous Sync mode, though it happens more often with Continuous Sync, where syncs run approximately every 5 minutes. In Daily mode the usual case is a pre-operation sync that has not finished before the operation starts.

When a sync overlaps an operation, results are affected in two ways.

Review the results of every bulk operation and automated task, and avoid scheduling them alongside known external group changes. See Bulk Operations and Automated Tasks.

Big Organization Sync Mode

For large organizations, Sync Mode can be set to Continuous Sync via Atlassian Guard instead of the default Daily mode, in Settings. This mode applies group, role, and user changes from your organization's Atlassian Guard audit log approximately every 5 minutes, and a daily quick sync keeps user last-active dates current. A full sync still runs, on a weekly cadence, to verify the complete data set and guarantee accuracy.

Note: Continuous Sync requires Atlassian Guard to be enabled on your organization. If Atlassian Guard is not enabled, only Daily mode is available.

Continuous Sync mode replaces the Daily Scheduled Sync row above with the following sync types. The other four sync types (Initial Full Sync, Pre-Operation Sync, Manual Sync, Post-Operation Sync) work the same way in either mode.

Continuous Sync is recommended for large organizations, where near-real-time updates from Atlassian Guard keep user, group, and role changes current while the weekly full sync guarantees complete accuracy, without the overhead of a daily full sync. It is not limited to large organizations: any organization with Atlassian Guard enabled can switch to Continuous Sync to benefit from near-real-time data.

Sync operations also run in parallel in this mode - the audit-log sync can apply changes while a full sync is still in progress, instead of waiting for it to finish.

Enable Continuous Sync, and configure its schedule fields, in Settings.

Performance Benchmarks

Sync duration depends on the total number of users and groups in your Atlassian organization. These benchmarks are based on observed production data.

Bulk group membership changes and role changes have been validated at scale up to 5,000 users.

SCIM and Identity Provider Sync

If your organization uses an Identity Provider (IdP) such as Okta, Azure AD, or Google Workspace with SCIM provisioning, user and group changes originate in the IdP and propagate to Atlassian via SCIM. The app's sync process then picks up these SCIM-provisioned changes from the Organization API.

This creates a two-stage pipeline:

1. IdP to Atlassian - Your IdP pushes changes via SCIM to Atlassian Cloud (timing depends on your IdP configuration)

2. Atlassian to App - The app's next sync cycle reads the updated data from the Organization API

The total delay before changes appear in the app is the sum of both stages. For time-sensitive changes, trigger a manual sync after confirming the SCIM provisioning has completed in admin.atlassian.com.

When to Trigger Manual Sync

A manual sync ensures the app reflects the latest organization state. Trigger one before any of these scenarios:

• Before a major bulk operation - Ensures you are acting on current user data, not stale records from the last scheduled sync

• After changes in admin.atlassian.com - If you added or removed users, changed group memberships, or modified product access outside the app

• After SCIM provisioning changes - When your IdP has pushed updates and you need them reflected immediately

• Before running an automated task for the first time - Verify the saved filter returns the expected users with current data

• After an API key renewal - Confirms the new key works and the sync completes without errors

Trigger a manual sync from the User Browser by clicking the "Sync Users" button.

What Gets Synced

Each sync cycle updates the following data in the local Forge SQL database:

• User accounts - Name, email, account status (active, suspended, deactivated, closed), last active timestamp

• Group memberships - Which groups each user belongs to, including SCIM-provisioned groups

• Product access - Which Atlassian products each user can access (Jira Software, JSM, Confluence, Jira Product Discovery, Bitbucket, Compass)

• Site assignments - Which sites each user has access to in multi-site organizations

• Roles - User roles across the organization (Organization Admin, Site Admin, User Access Admin, etc.)

Data Freshness

The data shown in the Dashboard and User Browser is only as fresh as the last completed sync. Keep these points in mind:

• The daily scheduled sync runs once every 24 hours. Changes made between syncs are not visible until the next sync completes.

• Pre-operation syncs run automatically before bulk operations and automated tasks, reducing the window for stale data.

• The "Last Synced" timestamp in the User Browser shows when the most recent sync finished.

• If user counts in the Dashboard seem incorrect, a manual sync usually resolves the discrepancy.

Troubleshooting

Sync is taking longer than expected

Sync duration scales with the number of users and groups. For large organizations (1,000+ users), syncs can take 20 minutes or more. For very large organizations (100,000+ users), expect 24+ hours for a full sync. This is normal and does not indicate an error. Do not trigger additional syncs while one is in progress.

User Browser shows outdated information

If the User Browser does not reflect recent changes:

1. Check the "Last Synced" timestamp to see when data was last refreshed

2. Click "Sync Users" to trigger a manual sync

3. Wait for the sync to complete (check the sync status indicator)

4. Reload the User Browser page

Sync fails or does not complete

Common causes for sync failures:

• Expired Organization API Key - Check the key status in Settings. If expired, create a new key at admin.atlassian.com and update the app configuration.

• Invalid API Key permissions - The API key must have organization-level read access. Verify the key scope in admin.atlassian.com > Settings > API keys.

• Network timeout - Very large organizations may hit timeout limits during sync. If syncs consistently fail to complete, contact support.

Automated task ran on stale data

Automated tasks trigger a pre-operation sync before execution. However, if the pre-operation sync takes longer than expected (common in large organizations), the task may start before the sync finishes. To avoid this:

1. Schedule automated tasks during off-peak hours when sync completes faster

2. Run a manual sync and confirm completion before manually triggering an automated task

3. For critical operations, use manual bulk operations instead of scheduled tasks so you can verify data freshness first

If the task reported a partially failed status, some users were skipped because their data was still being updated. See Syncs Running Alongside Operations above.

Operation finished with a partially failed status

A bulk operation or automated task reports partially failed when it skipped one or more users. The most common cause is that a sync was updating those users at the moment the operation reached them, so the app skipped them instead of acting on unsettled data.

1. Open the operation results and check which users were skipped

2. Confirm the sync has completed (check the "Last Synced" timestamp)

3. Run the operation again for the skipped users

If group changes are arriving continuously from SCIM or another external source, schedule your operations outside those change windows.

Dashboard user counts do not match admin.atlassian.com

Small discrepancies between the app's Dashboard and admin.atlassian.com are expected between sync cycles. If counts differ after a sync:

• Confirm the sync completed (check "Last Synced" timestamp)

• Verify you are comparing the same scope (the app filters by the selected site; admin.atlassian.com shows organization-wide totals)

• JSM customers, JPD contributors, and Confluence guests are not counted as billable users

SCIM changes not appearing after sync

If SCIM-provisioned changes are not visible after a manual sync:

1. Verify the SCIM provisioning completed in your IdP's audit log

2. Check admin.atlassian.com to confirm the changes propagated to Atlassian

3. Trigger another manual sync in the app - the first sync may have started before SCIM provisioning finished

Related Pages

• Sync Functionality - Sync controls in the User Browser

• Searching and Filtering - Finding users after sync

• Creating Automated Tasks - Tasks that depend on synced data

• Dashboard - User counts and activity metrics

• Settings - Configuring sync schedule

• Organization API Key - API key required for sync