Skip to main content

Group to Role Mapping

Group sync becomes truly valuable when it helps you manage access cleanly at scale.

In AxonFlow Enterprise, the right mental model is:

  • SCIM synchronizes identity and group membership from the IdP
  • AxonFlow roles define what users can do inside the platform
  • tenant admins align those two worlds so access follows enterprise identity structure instead of manual one-off changes

Why This Matters​

For small teams, manual user and role administration is usually tolerable.

For larger teams, it becomes painful quickly:

  • IAM teams want access controlled from the system of record
  • platform owners want role assignment to be predictable
  • security teams want less manual drift
  • auditors want a defensible story for how access is granted and removed

That is why group-based access alignment matters so much for enterprise AxonFlow rollouts.

Do not start with role mapping on day one of SCIM setup.

Safer order:

  1. validate user provisioning first
  2. validate user updates and deactivation
  3. enable group sync for a pilot group
  4. confirm the right groups are landing in the right tenant
  5. then align synced groups with AxonFlow roles

This reduces the risk of accidental over-permissioning caused by a bad first sync.

What Gets Synced​

When the IdP provisions a group through SCIM, AxonFlow stores the synced group identity and membership information.

Typical group payload:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
  "displayName": "AxonFlow-Engineers",
  "externalId": "idp-group-456",
  "members": [
    { "value": "user-id-1" },
    { "value": "user-id-2" }
  ]
}

Operationally, the important outcomes are:

  • the group exists in the tenant
  • its external identity is stable
  • membership changes continue to sync

How to Think About the Mapping​

A common enterprise pattern looks like this:

IdP groupIntended AxonFlow role outcome
AxonFlow-Platform-Adminstenant admin or equivalent high-trust platform role
AxonFlow-Developersday-to-day engineering role
AxonFlow-Analystsanalytics or read-heavy governance role
AxonFlow-Auditorsevidence and review-oriented read access

The goal is not to mirror every IdP group into a distinct AxonFlow role. The goal is to map the identity structure that actually matters to AxonFlow operating boundaries.

How Role Sync Works​

When SCIM provisions or updates group membership:

  • SCIM-assigned roles (source: scim) are automatically added when a user joins a group and removed when they leave. This is fully managed by the SCIM sync.
  • Manually-assigned roles (source: manual) are never touched by SCIM sync. Admin-granted roles persist regardless of group membership changes.
  • Group deletion: When a group is deleted via SCIM, former members have their SCIM-assigned roles re-evaluated. Manual roles are unaffected.
  • Role mapping changes: When you change which role a group maps to, all current members are re-synced to the new role.

This distinction prevents SCIM sync from accidentally removing admin-granted permissions while keeping group-based roles automatically managed.

Operator Workflow​

The safest workflow is:

  1. create the AxonFlow custom roles you actually need
  2. confirm synced groups appear from your IdP
  3. review group names for stability and clarity
  4. map only the groups that should drive access
  5. verify the effect on a small pilot set of users

Groups that are synced but not mapped can still be useful operationally, because they let you stage the identity rollout before connecting it to access enforcement.

Design Guidance for Staff Engineers and IAM Owners​

Keep the role model small​

If every small team variation becomes a unique role, the enterprise access model becomes harder to reason about and harder to audit.

Prefer a compact set of roles that reflect:

  • tenant-admin capabilities
  • engineering build and deploy access
  • read-only oversight and review access
  • specialized governance or compliance responsibilities

Map stable IdP groups, not temporary org charts​

Avoid tying access to short-lived project groups when a more durable platform or function-oriented group exists.

Separate identity sync from policy and governance​

Role mapping decides who can do what in enterprise surfaces. It should complement, not replace:

  • policy controls
  • approval workflows
  • audit logging
  • environment separation

Common Pitfalls​

  • enabling group sync and role alignment before user provisioning is stable
  • mapping very broad corporate groups directly into privileged AxonFlow roles
  • creating too many tenant-specific roles without clear governance
  • assuming synced groups alone are a sufficient governance model

Validation Checklist​

Before expanding group-based access broadly, verify:

  • the pilot group syncs correctly
  • users land in the expected tenant
  • role assignments match the intended access model
  • removing a user from the group has the effect you expect
  • the mapped role is still the right one after real admin review

When to Use Group Mapping Aggressively​

Group-to-role mapping is especially valuable when:

  • multiple platform teams share one enterprise tenant
  • you need repeatable onboarding for engineers across a large company
  • security or IAM teams own access lifecycle
  • you are moving from trial usage to a governed production rollout
Last updated on