Skip to main content
When a user signs in through SAML SSO, Enterprise Knowledge can evaluate their metadata attributes and automatically assign them to a team and, optionally, to all projects within that team — with the appropriate role.
Automated Management and Access Controls are independent features, but they are typically used together. See SAML Access Controls for the companion guide.

​
Prerequisites

Before enabling automated management:
  • SAML SSO must be configured and sending metadata attributes on login
  • The SAML assertion must include stable attributes to match against
  • Target teams must already exist in EK, for instructions on creating teams see Teams Management
Validate attribute names and values from a few successful SSO logins before enabling automation.

​
Rule Structure

Navigate to Super Admin → Teams → Automated Management to configure rules. Each rule includes:
FieldRequiredDescription
SAML Attribute NameYesThe attribute key from the SAML assertion
Attribute ValueYesThe exact value to match
Target TeamYesThe team to assign the user to
Auto-add to team projectsOptionalAdds the user to all non-default projects in the team
Default Project RoleOptionalAdmin, Editor, or Viewer
Forced continuous team reassignmentOptionalMoves users on every sign-in, not just first login

​
Team Assignment Behavior

On each SSO sign-in, EK evaluates configured rules against the user’s SAML metadata.
User StateOutcome
No team yetAssigned to target team
Already in target teamNo change
In a different teamMoved only if forced reassignment is active
Team owner with other membersNot forcibly moved (prevents orphaned ownership)
If multiple rules could match the same user, only one match is applied. Avoid overlapping rules.For first-time SSO onboarding, reassignment is always forced to establish correct placement.

​
Auto-Add to Projects

When Auto-add to team projects is enabled on a rule, EK adds the user to non-default projects in the target team. The user is only added to projects they are not already a member of. Role assignment priority:
  1. Matching conditional role override (if any)
  2. Default project role defined on the team rule
Project assignment runs asynchronously. Team membership may appear before all project memberships complete.

​
Conditional Role Overrides

Role overrides allow a different project role to be assigned based on additional SAML attributes. Example:
  • Team rule: department = engineering, default role → Viewer
  • Role override: level = manager → Admin
Result:
  • All engineering users are added to the team as Viewer
  • Users who also have level = manager receive Admin on auto-added projects
If multiple conditional role overrides could match the same user, only one override is applied. Keep overrides mutually exclusive.

​
Team Reassignment Restrictions

Found in Super Admin → Teams → Automated Management → Team Reassignment Restrictions, these settings control what happens to project memberships when a user moves between teams. All three default to off (non-destructive). Team Reassignment Restrictions
SettingDescription
1. Remove user from old team’s projectsMaster switch. Removes old project memberships on reassignment.
2. Projects owned by user follow themDepends on setting 1. Owned projects move to the new team.
3. Remove old team members from followed projectsDepends on settings 1 and 2. Cleans up old team access on moved projects.
If ownership cannot be safely transferred during reassignment, EK applies safeguards to prevent broken ownership states.

​
Configure Automated Management Rules

1

Open Automated Management

Go to Super Admin → Teams → Automated Management and click Add Rule.
2

Enter SAML matching criteria

Provide the SAML Attribute Name, Attribute Value, and Target Team.New Team Assignment Rule
3

Configure optional settings

Decide whether to enable Auto-add to team projects and/or Forced continuous team reassignment.
4

Set project role (if auto-add is enabled)

Choose a Default Project Role and optionally add Conditional Role Overrides.
5

Save and configure reassignment restrictions

Save the rule, then optionally configure Team Reassignment Restrictions to define behavior when users change teams.
6

Test

Test with real SSO users representing each expected metadata pattern before enabling in production.

​
Rule Design Best Practices

  • Use stable identity-provider attributes — avoid volatile or frequently changing values
  • Keep attribute names consistent with exact SAML claim names
  • Avoid overlapping rules that can match the same user
  • Start with least privilege (Viewer) and elevate only where needed
  • Document rule ownership and schedule periodic reviews

​
Testing Checklist

After configuration, verify each scenario:
  • Allowed users are placed in the correct team
  • Project auto-add completes with the correct role
  • Forced reassignment works as expected (if enabled)
  • Reassignment restriction settings behave correctly during team movement

​
Troubleshooting

  • Confirm a matching team assignment rule exists
  • Confirm the target team still exists
  • Verify the rule value and IdP value match exactly
  • Enable Forced continuous team reassignment if the user already belongs to another team and must be moved
  • Confirm Auto-add to team projects is enabled on the matched rule
  • Confirm the team has non-default projects
  • Confirm a valid project role (Admin, Editor, or Viewer) is set
  • Allow a short delay for asynchronous background processing
  • Confirm the role override is attached to the correct team assignment rule
  • Confirm the additional attribute/value actually exists in the user’s SAML metadata
  • If the default role is being applied, it means no conditional override matched

​
Operational Guidance

  • Treat assignment rules as security-sensitive configuration
  • Use change management processes for production updates
  • Re-test after any IdP claim changes
  • Periodically review rules and remove stale mappings