Non Synched User Access

Sachindran Gangaiya

Environment: We use Google Workspace for Atlassian SSO, but it is only enabled for specific Organizational Units (OUs). Contractors bypass this via a Non-SSO Exception authentication policy, restricting them to a single space in confluence.

The Problem: A user returning after four years has a stale, deactivated account causing provisioning conflicts.

Constraints:

• Deleting the stale account requires a 14-day waiting period, which is too long.
• The Atlassian UI does not permit converting this existing standard user directly into a guest.
• Current Workaround: We temporarily moved the user to the SSO-synced "Full-time employees" OU, but this grants broader access than permitted.

Goal: We need a method to immediately provision this returning user as a restricted guest with access to only one specific space, bypassing the 14-day deletion period and UI limitations.

Does this returning user share the same email domain as your full-time employees, and is that domain claimed in your Atlassian organization settings?

Ciro

Hey, good question.

Short version: a guest isn't an option for this person, but you can get the same result with the account you already have.

1. Guest is ruled out by policy. The Confluence guest docs say you may not convert current or former paid users to guests, and a guest's email domain can't match any domain of your organization. Someone who had a licensed account four years ago falls under the first rule.
2. If the account is a managed account (your claimed domain), reactivate it instead of deleting it: Directory > Users, filter Account type by Managed accounts, select the user > Reactivate account. Access comes back right away, so the 14 days don't apply.
3. Move them into the Non-SSO exception policy: Security > User security > Authentication policies > Edit on the policy they're in now > Members > Change member's policy. A member can only be in one policy at a time, so this takes them out of the SSO one without touching the employee OU.
4. Keep them to one space with permissions: give them the Confluence User role, check which groups the old account still belongs to (those may grant other spaces), and add them only to the space they need. Spaces open to all licensed users or to anonymous access will still show up.

If their email isn't on your claimed domain, the account isn't managed by you. Authentication policies only take managed accounts, so you'd just grant Confluence access again and limit it with space permissions.