.png)
Connect Rippling to Confluence so knowledge base access is provisioned at hire, scoped by department and role, and fully deprovisioned at offboarding — with Rippling as the identity source for every Confluence user.
thePeopleStack configures the Rippling–Confluence integration with SSO enforced and group membership mapped to Rippling's department and role structure — ensuring new hires access the right Confluence spaces on their start date and access is revoked completely at offboarding. We configure the offboarding workflow to transfer page ownership before deactivation, protecting institutional knowledge through employee transitions.
For clients using Confluence as part of the broader Atlassian suite alongside Jira, we configure Atlassian Access as the unified provisioning layer — ensuring both products are provisioned and deprovisioned consistently from Rippling's employee lifecycle events.
Confluence is deployed by thePeopleStack's Rippling clients primarily as a US team knowledge base and documentation platform, with space permissions and group access configured around US org hierarchies and Rippling's US employee data.
Canadian and cross-border operations: Canadian employees are provisioned into Confluence through the same Rippling sync. thePeopleStack confirms that Atlassian data residency settings and PIPEDA-relevant considerations for employee access data are addressed for cross-border Confluence deployments.
Rippling acts as the SAML identity provider for Confluence, allowing employees to authenticate using their Rippling credentials. SCIM provisioning creates Confluence accounts for new hires and deactivates them at offboarding. Rippling department and team data drives Confluence group membership, controlling which spaces and pages each employee can view and edit.
Yes. Rippling department and role data maps to Confluence's group structure, which controls space-level permissions. Engineering, HR, Finance, and other departments each receive access to their relevant Confluence spaces automatically at hire — without a Confluence admin manually adding each new employee to the correct groups.
With proper configuration, Confluence page and space ownership for the departing employee can be transferred to their manager or a designated successor before the account is deactivated. Without this step, pages owned by a departed employee become effectively orphaned — still visible but without an active maintainer flagged in Confluence's ownership metadata.
Yes. For organizations using both Jira and Confluence through Atlassian's platform, the Rippling integration can be configured to provision access to both products from a single hire event — using Atlassian Access (SSO and SCIM) to manage both Confluence and Jira through the same Rippling identity layer.
A standard configuration covering SSO, SCIM provisioning, group membership mapping, and offboarding deprovisioning typically takes 3–5 hours. Complex Confluence deployments with many spaces, granular space-level permissions, or Atlassian Access configurations spanning multiple Atlassian products may require additional scoping.
