Project Automated Management

Automatically add users to specific projects — with the right project role — the moment they sign in through SAML-based Single Sign-On (SSO), based on the attributes their Identity Provider (IdP) sends. This guide covers project assignment only. Project rules are fully independent of team assignment: a user can be added to specific projects by attribute rules whether or not they match any team rule. This document is written for administrators configuring the feature from the Super Admin dashboard of Enterprise Knowledge (EK).

​

What project assignment does

When a user authenticates via SAML SSO, their IdP includes a set of attributes in the SAML response — for example department, role, memberOf, group, or country. EK compares those attributes against the project assignment rules you have configured and, on a match:

• Adds the user to each of the rule’s target project(s) (skipping any they already belong to).
• Applies a project role on each project — a default role, or a different role if a conditional override matches.

Rules are evaluated on every SSO sign-in, so access stays current as IdP attributes change.

​

Prerequisites

Before you can use project auto assignment:

1. SAML SSO must be configured for your tenant, and your IdP must send the attributes you intend to match on. If an attribute isn’t present in the SAML response, no rule referencing it can match.
2. You must have Super Admin access to EK. Some Super Admin roles are view-only — in that mode the rules are visible but the create/edit/delete controls are hidden.
3. The target projects must already exist. A rule references existing projects; it cannot create them.

​

Where to configure it

There are two entry points, both under Super Admin:

​

Automated Management tab (all project rules)

Super Admin → Projects tab → Automated Management sub-tab. This lists every project assignment rule in the system and lets you create, edit, and delete them. Each rule can target one or many projects.

​

Per-project shortcut (rules for one project)

Super Admin → Projects tab → Project Management. Find the project and click the shield icon (“SAML Project Rules”) in its Actions column. A modal opens listing every rule that targets that project, where you can add, edit, or delete rules.

• In this modal the current project is locked as a target and cannot be removed.
• Editing a rule here may also affect its other target projects, because a single rule can target many projects at once.

​

Anatomy of a project rule

​

How attribute matching works

This section governs whether your rules behave as you expect. The matcher’s mental model is: “everything is treated as a multi-value set, except one genuinely ambiguous case.” Attribute matching uses the same engine as SAML Access Controls. See Matching behavior matrix in that guide for the general reference; the project-specific matrix below includes wildcard behavior.

​

The rule side (what you type)

Whatever you enter in Attribute Value(s) is always treated as a comma-separated set of tokens. Each token is a required value.

• A rule with a single value (Finance) matches when the user’s attribute contains Finance.
• A rule with multiple values (Finance, US) matches only when the user’s attribute contains all of them — a subset (⊆) match: the rule’s required set must be contained within the user’s set.

Matching is case-insensitive, and surrounding whitespace is trimmed.

​

The user side (what the IdP sends)

How the user’s incoming value is interpreted depends on its wire shape and one per-rule toggle:

​

Toggle: “IdP packs multi-values into one string”

Some IdPs cram several values into a single attribute value as one comma-separated string (e.g. Accounting,Admin,US). By default EK treats a single attribute value as one literal token, so Accounting,Admin,US would not match a rule value of Accounting.

• Off (default): the user’s single string is one literal value; embedded commas are preserved. Use this when the attribute really is single-valued.
• On: the user’s single string is split on commas into a set before matching. Use this when your IdP packs multiple values into one string.

This toggle only affects how the user’s single-string value is interpreted. It never changes how your rule value is read (rule commas are always separators), and it is ignored when the IdP already sends native multi-value attributes (those are always a set).

​

Behavior matrix

​

Toggle: “Wildcard (substring) match”

• Off (default): each rule token must match a user token exactly (after case-insensitive trimming).
• On: each rule token matches if it appears anywhere inside one of the user’s tokens (case-insensitive substring). For example, rule value val2 matches an incoming value of val1val2val3. For multi-token rules, every rule token must be contained in some user token.

Wildcard is independent of the CSV toggle: CSV controls how the user’s string is split into tokens; wildcard controls how each token is compared.

​

Conditional role overrides

A rule’s Default Project Role applies to everyone the rule matches. Use Conditional Role Overrides to grant a different project role to a subset of matched users, based on an additional attribute. Each override has its own:

• Attribute name and value(s)
• Project role (Viewer / Editor / Admin)
• CSV toggle (“IdP packs multi-values into one string”)
• Wildcard toggle

Overrides are evaluated within the rule that owns them, and only for users who already match that rule’s main condition.

​

Which override wins

When more than one override matches, EK picks the most specific one — defined as the override requiring the largest set of values. If two overrides tie on specificity, the earliest-created one is chosen (and a warning is logged); restructure your overrides to remove ambiguous overlaps rather than rely on the tie-break. If no override matches, the rule’s Default Project Role is used.

​

Union semantics and role precedence

​

Union semantics

Project rules use pure union semantics — there is no “one project per user” constraint:

• Every project rule whose condition matches contributes its target projects.
• The user is added to the union of all matched projects (skipping any they already belong to).

​

Role precedence

• Project roles rank: Viewer < Editor < Admin.
• Within a single rule, the role is resolved from its most-specific matching override, else the rule’s default.
• When the same project is targeted by multiple matched rules that resolve to different roles, the highest-privilege role wins — so a user is never under-provisioned relative to any matched rule.
• Existing project roles are never downgraded. If the user is already a member of a target project, their current role is preserved.

​

Step-by-step configuration

​

Create a project assignment rule

​

Edit or delete a rule

• Use the edit and delete icons on the rule’s row in the Automated Management list, or open the per-project shield icon modal.
• Deleting a rule removes its target list and role overrides but does not change any project memberships users already have.

​

Manage rules for a single project

​

Worked examples

​

Example 1 — Group to a project as Editor

Goal: Grant users whose memberOf contains KB-Editors editor access to the “Knowledge Base” project.

• Attribute memberOf = KB-Editors
• Default Project Role Editor
• Target Projects: Knowledge Base

​

Example 2 — IdP sends a single packed group string

Goal: Same as above, but the IdP sends memberOf as one string like KB-Editors,All-Staff,VPN-Users.

• Attribute memberOf = KB-Editors
• IdP packs multi-values into one string = On
• Default Project Role Editor
• Target Projects: Knowledge Base

Because the CSV toggle is on, the packed string is split and KB-Editors is matched as one of the tokens.

​

Example 3 — Require two attributes together

Goal: Only users who are in both US and Engineering get access to the “US Engineering Docs” project.

• Attribute groups = US, Engineering (two chips)
• Target Projects: US Engineering Docs

The rule matches only when the user’s groups set contains both values.

​

Example 4 — Base role plus an elevated override

Goal: Everyone in department=Support gets Viewer access to the “Support Runbooks” project; team leads get Editor.

• Attribute department = Support, Default Project Role Viewer
• Override: Attribute title = Lead → Editor

A department=Support, title=Lead user gets Editor; a plain department=Support user gets Viewer.

​

Example 5 — Same project from two rules

• Rule A: role=analyst → Project X as Viewer.
• Rule B: role=lead → Project X as Editor.

A user matching both ends up on Project X as Editor (highest privilege wins).

​

Behavior, edge cases, and important notes

• Additive only. Rules never remove a user from a project and never downgrade an existing role. Deprovisioning is a separate, manual action.
• Independent of teams. Project rules do not affect team membership, team roles, or the user’s home / billing team.
• Evaluated on every sign-in. Changes to a user’s IdP attributes take effect the next time they sign in via SSO. Creating a new rule does not retroactively apply to users who aren’t currently signing in.
• Applied in the background. After sign-in, project additions are processed by an asynchronous task, so very large target sets may take a short while to fully apply.
• Already-a-member projects are skipped. Users are only added to projects they don’t already belong to; existing roles are preserved.
• Missing roles are skipped. If a resolved role doesn’t exist on a particular project, that project is skipped rather than failing the whole login.
• Deleted target projects are ignored safely (and logged).
• Empty rule values are rejected. A value that reduces to nothing after trimming and removing empty comma slots is not accepted, because it would match nothing.
• Values are normalized for storage. Whitespace around each value is trimmed and empty slots dropped; original casing is preserved for display, but matching is case-insensitive.
• Auditing. Creating, updating, and deleting project rules and their role overrides is recorded in the Super Admin audit log.

​

Troubleshooting

​

Quick reference