Role and Team Sync

In the Platform Management → Single Sign-On settings page, the Sync Configuration section decides how members get their Flashduty roles and teams when they sign in via SSO:

• SAML2.0 / OIDC / CAS: matching by the role names / team names returned by the identity provider (claim / attribute names). When no name matches, default roles / default teams apply only to members actually created during this sign-in; existing members keep their assignments.
• LDAP: does not use name matching; instead it matches the user’s LDAP Group DN against mapping rules. See LDAP Role and Team Synchronization.

Sync runs on every SSO sign-in. This page describes the sync configuration and matching rules for SAML2.0 / OIDC / CAS.

​

Sync Configuration Fields

The Sync Configuration section contains the following fields: Defaults have no separate toggle: clear the corresponding selection to turn fallback assignments off. To stop SSO from managing roles or teams, disable the corresponding sync option; clearing defaults alone does not prevent valid mappings from replacing existing assignments on every sign-in.

​

Matching Rules

Role/team name matching happens on the Flashduty server, with these rules:

​

Name normalization

• The claim / attribute value can be a single string or an array of strings; non-string elements in an array are ignored.
• Each name is trimmed of leading/trailing whitespace; empty names and duplicates are removed. Deduplication is case-sensitive — Ops and ops are two different names.
• Matching is exact and case-sensitive: Ops does not match ops.

​

Role matching

• The preset roles Admin, Responder, and Viewer are always eligible (no enabled-state requirement).
• Custom roles must be enabled to match; a disabled role with the same name is never hit.
• When one name hits several roles, the role with the smallest role_id wins (e.g. if the account has several roles named Ops, the smallest ID is used).
• Names that match no role are skipped (the server logs a warning); other names are still resolved.

​

Team matching

• Only non-deleted teams are matched.
• Also exact and case-sensitive; duplicate team names resolve to the smallest team_id.
• Unmatched team names are skipped as well.

​

Default roles / default teams fallback

• Eligible defaults apply only when this sign-in actually creates a new member and no name matches for that dimension. Roles and teams fall back independently of each other. Existing members do not receive defaults on sign-in.
• Default roles: the preset roles (Admin / Responder / Viewer) are always eligible; a custom default role must exist and be enabled, otherwise it is skipped with a warning logged.
• Default teams: must exist and not be deleted, otherwise they are skipped.
• The resolved role IDs / team IDs are deduplicated and sorted in ascending order.

​

Where Each Protocol Reads the Names

​

Protocol Switching and Field Retention

When saving the SSO configuration, the console discards sync fields that do not belong to the current protocol (so switching protocols leaves no stale config behind):

• LDAP: keeps the Group field, the Group DN mapping rules (role_team_mapping), and the default roles; roles, teams, and default_team_ids are not saved.
• SAML2.0 / OIDC / CAS: keeps roles, teams, default_role_ids, and default_team_ids; group and the mapping rules are not saved.

​

When Sync Takes Effect and Overwrite Semantics

• With sync enabled and matching names, valid mappings update the corresponding roles or teams on every SSO sign-in.
• Valid mappings replace assignments rather than append to them, including manually assigned roles or team memberships; they are not merged with existing assignments.
• Without matching names, eligible defaults apply only to members actually created during this sign-in; existing members keep their corresponding roles or teams.
• Without matching names or eligible defaults, that dimension is not synced: new members follow the existing creation flow, and existing members’ roles or teams are not cleared.
• When both sync switches are off, sign-in never changes a member’s roles or teams.

A first SSO sign-in does not necessarily create a new member. Members already created or invited by an administrator, and existing members linked to a stable user ID for the first time, do not receive defaults. Defaults apply only when Just-In-Time (JIT) provisioning creates a new member record during this sign-in. Changing defaults does not reassign existing members’ roles or teams.