Org modelling and SSO
Manage people once. In your directory.
Any tool with its own invitation workflow is where a leaver keeps access three weeks later. Map your IdP groups to teams and roles once, and everyone is in from their first login.
IdP group mapping
Group mapping
Map the group once, then stop managing people
A mapping entry names a directory group and says what holding it means. It’s small on purpose. Whoever approves it should be able to read it.
The teams
The teams the group grants, by path, so engineering/platform/cloud is one value, not three lookups. Teams nest as deep as your organisation goes. A team is a Resource, so it sits in the catalogue beside what it owns. Everyone who joins the group later gets it too.
The role
Lead, member or viewer, granted on every team in the list. They’re the same slugs the permission model uses, so nobody keeps two vocabularies in step by hand. Custom roles come later. At launch, a Tenant Admin delegates a specific permission instead.
The tenant
Holding any team in a tenant makes you a member of it. Tenant Admin is granted separately, and on purpose. Tenant Owner and instance administration never come from a mapping at all.
Cycloid for your team
What directory-driven access changes for each reader
Stop being the access queue
The problem
Onboarding is a ticket to you. Offboarding is a ticket you hear about late. Both end with somebody typing a name into a tool.
With Cycloid
Mapped groups provision on first login or first SCIM push. Removals take effect on the next request, not the next login.
The outcome
Joiners and leavers stop being your workload, because they were never your decision.
Day one is a login
The problem
You join a team, then wait for an invitation to a platform you were told you already had.
With Cycloid
You’re in the directory group, so you log in and your teams are there, with the role the mapping gives.
The outcome
Nothing to request, and nobody to chase for it.
One access model to defend
The problem
The access review is a spreadsheet exported from four systems, and somebody has to explain how a leaver’s access was actually revoked.
With Cycloid
Access comes from directory membership. Provisioning events are audit-logged, and every membership records which source granted it.
The outcome
The access model has one owner, and the evidence comes from the same place as the control.
How it works
From a verified domain to a clean exit
01 · Prove you own the domain
Cycloid issues a DNS TXT challenge, and SSO applies only once the record resolves. One tenant holds a verified domain at a time.
02 · Connect your IdP
Each tenant connects its own, over OIDC or SAML 2.0. MFA stays with your IdP by default.
03 · Map your groups
Groups become teams and a role. A group with no mapping grants nothing.
04 · Switch on SCIM
SCIM 2.0 pushes changes as they happen, because login-time sync can’t handle leavers. It never creates teams.
05 · Someone leaves
Set them inactive and their sessions end straight away. Drop them from a group and that team’s access goes on their next request.
Underneath all of it, every membership records where it came from. An admin, a particular IdP, SCIM and VCS sync each replace only what they own. Anyone who has run two directories through a merger will see why that matters. Nobody loses the teams the other directory gave them. Change a role at the directory, because a hand edit to something it still asserts lasts only until its next sync.
From a verified domain to a clean exit
The short version
What to tell your IT team
8
identity providers to connect
4
sources a membership can come from
1
tenant per verified domain
0
invitations for a mapped group
Deploy the staging database for platform-cloud.
Refused. You’re no longer a member of that team, so the action isn’t available to you here either.
Denied · staging database
Layer 1
Reason
Team membership removed by SCIM
Took effect
On the next request
Working with your assistant
Deprovision somebody and their assistant goes with them
Does the assistant get its own permissions?
No. There’s no service account and no elevated assistant role. If you can’t deploy to production, neither can the assistant you’re talking to, in Cycloid’s own assistant or any compliant MCP host.
An assistant acts as the person talking to it. It has no service account and no role of its own. That’s also how deprovisioning reaches it. Its tools are put together per request and checked against current membership. Remove somebody from a team and their assistant loses that team’s tools on the next request.
One identity model sits under the portal, the API and the assistant. There’s no separate AI access review.
Frequently asked questions
Entra ID, Okta, Keycloak and generic OIDC first, over OIDC or SAML 2.0, with Google Workspace, GitHub, GitLab and SAML alongside. Pure on-premise LDAP without SCIM isn’t covered at launch.
Yes. Inactive suspends the user and ends their sessions at once. A delete removes them from the tenant. A group removal takes that team’s access away on their very next request, not their next login.
Not for mapped groups. People log in and their teams are already there. Manual invitations still exist for anyone outside a verified domain, such as contractors and agency staff.
Nothing gets lost. Each source replaces only the memberships it granted, so logging in through one directory never removes what another directory or an admin gave you. Mergers stop being scary.
Bring your IdP and your messiest group
Twenty minutes, your directory connected, and one group mapped to a team. Then remove somebody from it in your IdP while we watch what happens on our side.