Resources

• Figma Design File

• Figma Clickable Prototype

Overview

Team-Scoped Channel Membership Policies extend Mattermost's attribute-based access control (ABAC) capabilities to Team Admins, allowing them to manage channel membership rules for their own team without System Admin intervention. This feature builds on earlier ABAC phases (system-wide policies in the System Console and channel-specific rules in Channel Settings) but adapts them to the Team Settings modal context. It empowers team administrators to enforce confidential discussions and membership restrictions at the team scope.

Open

Goals:

• Empower Team Admins: Enable Team Admins (and System Admins acting in a team context) to create and manage Membership Policies for private channels in their team, reducing reliance on System Admins for channel access control.

• Consistency with Phase 1 and 2: Reuse UX patterns from global policies and channel-level rules. The team-level UI offers both Simple and Advanced rule editing, "Test Rules" preview, and a per-channel auto-sync (auto-add) toggle just like the System Console, ensuring a minimal learning curve for admins.

• Non-Disruptive Integration: Seamlessly integrate into the Team Settings modal. All policy changes are staged within the modal and only applied on Save (with confirmation if needed), aligning with the modal's unsaved-changes paradigm.

• Respect Global Controls: Enforce that team-level policies cannot override system-wide policies. If a channel is subject to any global access policy, or if ABAC is disabled globally, the team UI reflects those constraints (e.g. fields locked, policies hidden). Team admins only manage channels in their team, and cross-team policies remain under system control.

• Attribute Value Confidentiality: Prevent Team and Channel admins from discovering attribute values they do not hold through write-path (rule authoring) or read-path (viewing system policy rules) vectors. Enforce the Need-to-Know principle at the UI layer.

Access Policy Object

Each access policy consists of: a Name (unique within its team), a set of Access Rules, an Assigned Channels list. The policy also carries a Type designation:

• Team Policy: Scoped to a single team (all assigned channels are in one team). Created by Team Admins or System Admins from the Team Settings modal.

• System Policy: Can span multiple teams (assigned channels from more than one team). Typically created or edited by System Admins in the System Console. Team Admins cannot create these. When such a policy exists and includes channels from the Team Admin's team, it will appear in their list (so they are aware of it), but it will be locked for editing and rule details will be suppressed (see View System Policy section below).

Policies created via Team Settings are initially Team Policies (only channels of that team). If a policy's channel assignments expand beyond one team (via System Console), it becomes a System Policy.

Team Admin Experience

Membership Policies Tab (Team Settings List View)

A new third tab in the Team Settings modal labeled "Membership Policies".

• Content Layout: In the Team Settings modal, the Membership Policies tab presents a list of all Membership Policies relevant to that team. Key UI elements and states:

  • Policy List Header: At the top, include a search field and filter controls. Search Bar with placeholder text "Search by name or channels". This filters the list in real-time to show policies whose name or assigned channel names match the query. UPDATED Show System Policies Toggle: A checkbox or toggle to include or exclude System Policies from the list. By default, this is OFF (hiding system-level policies, showing only Team Policies). When turned on, the list will also show system-level policies that affect this team. This default reduces clutter and keeps the team admin focused on policies they can manage, while still providing visibility into system policies on demand.

  • Policy List: List each policy as a row with: Name (policy name, with "System Policy" badge if applicable). Applies To: The number of channels in this team that the policy currently applies to (e.g. "5 channels"). Actions: an Edit button (with clickable row) to configure the policy. A Delete option (trash icon) is present if deletable (enabled only when the policy has 0 channels; otherwise disabled with tooltip "Remove channels before deleting"). For system policies, we show a lock icon and clicking on the policy row opens a read-only view, and Delete is not available at team level.

• Create Policy: At the top-right of the list (and bottom of empty state), provide a prominent "Add Policy" button.

• Modal Conventions: The tab uses the standard Team Settings styling. Any changes made will trigger the modal's Save bar appearance.

• Sync Status Footer: At the bottom of the list view, display a status line for policy synchronization, e.g. "Last synced 30 minutes ago. [Sync now]". The Sync now link triggers an immediate synchronization of membership for all channels under all policies in this team.

Open

Create/Edit Policy

When a Team Admin creates a new policy or edits an existing Team Policy, the UI navigates to the Policy Editor view within the Team Settings modal.

• Header: Title reflects the context -- "Create Access Policy" for a new policy, or "Edit Access Policy" for editing an existing one. A back arrow in the header returns to the policy list without saving (prompting if there are unsaved changes).

• Form Fields: The Policy Editor modal contains:

  • Policy Name -- Text input (required). If editing, pre-filled. Max length ~64 characters. Inline validation ensures it is not empty.

  • Access Rules: A section to define the membership criteria. By default, show the Simple Mode rule builder. Each rule row lets the admin pick a user attribute, an operator, and a value (or multiple values) to filter team members. The attribute value dropdown is filtered to show only values the current admin holds. Allow adding multiple rule rows (all conditions are combined with AND logic). UPDATED

  • Operator availability: When "Operators allowed for team and channel admins" is set to "Exact-match only", the operator dropdown in Simple mode only shows the "is" operator. When set to "All standard operators", all operators are available. UPDATED CEL editor availability: The Advanced (CEL) editor toggle (Simple vs Advanced) is only visible in the policy editor when the System Console setting "Allow team and channel admins to use the advanced rule editor (CEL based)" is set to True. When this setting is False, the Simple/Advanced toggle is hidden and team admins can only use the Simple rule builder. When the CEL editor is enabled, operator restrictions from the "Operators allowed for team and channel admins" setting are still enforced server-side regardless of editor mode -- the CEL editor cannot bypass operator restrictions. If a team admin writes a CEL expression using a restricted operator, the server rejects it on save with an inline error.

  • Test Rules -- Below the rules section, include a "Test Rules" button. Clicking this opens the Test Access Rules modal, allowing the admin to preview which team members satisfy the current rule set.

  • Assigned Channels: A section to assign the policy to channels in this team. Each entry displays the channel name (with the private channel lock icon) and a toggle for "Auto-add members". A Remove action appears for each channel. An "Add channels" button opens the channel selection dialog.

• Save/Cancel: The Policy Editor modal has its own Save and Cancel controls. Cancel closes the editor without applying changes (if any changes were made, prompt confirmation to discard). On Save, if any membership changes will occur in channels, the user is taken to a confirmation step before final apply.

Open

Confirmation Modal

When the Team Admin clicks "Save" in the Policy Editor (for create or edit), a confirmation modal appears to ensure they understand that saving the policy will trigger a membership sync for all assigned channels.

Note: Because multiple policies can apply to a single channel (System Policy + Team Policy + Channel Custom Rules), we cannot show the specific users who will be added or removed when saving a single policy. The actual membership impact depends on the combination of all applicable policies evaluated during sync. This matches the confirmation pattern used in the System Console.

Confirmation Variations

Policy Name Only Change: Skip confirmation modal. Save immediately with success toast.

Rules or Channels Modified: Show confirmation modal as specified above.

Open

Validation Logic

Before allowing save, the system must verify that the Team Admin's own user attributes satisfy the policy's access rules. This is the save-time enforcement of the self-inclusion check (the load-time enforcement hides non-matching policies entirely, as described in the Self Inclusion Check section above). This check runs when clicking "Save" in the Policy Editor.

Self-Exclusion Error (Hard Block)

Trigger: Admin attempts to save rules that would exclude themselves.

Display: Inline error banner at top of rules section (red background) with warning icon.
Message: "You cannot save these rules because they would remove your access to this policy. Adjust the rules to include your user attributes." Save button remains disabled until rules are corrected.

Open

Pre-read: UX Spec: Team-Scoped Channel Access Policies

Handling Pre-Existing Rules After Operator Restriction NEW

When a System Admin changes "Operators allowed for team and channel admins" to "Exact-match only", pre-existing team policies that were authored using now-disallowed operators (such as in, is not, contains, starts with, ends with) remain active but the access rules are hidden. This section defines how those policies appear to team admins and what actions remain available.

Scenario:

1. Operator restrictions are initially set to "All standard operators" (all operators permitted).

2. A team admin creates a policy with rules using the "in" operator, e.g., Program in (Yellow, Blue).

3. The System Admin later changes "Operators allowed for team and channel admins" to "Exact-match only."

4. A team admin (who holds Program = Yellow) navigates to this policy.

Behavior in List View: The policy remains visible in the Membership Policies list.

Behavior in Policy Editor View: The policy opens in a restricted state:

• Policy Name: Remains editable (name changes are safe and do not involve operator logic).

• Access Rules section: Suppressed -- follows the same pattern as system policy rule suppression. Instead of the rule table, display an informational banner. Heading: "Access rules are restricted". Body Text: "This policy contains rules using operators that are no longer permitted in your configuration. Contact your System Admin to modify this policy's rules."

• Assigned Channels section: Remains visible and fully functional. The team admin can still add/remove channels and toggle auto-add, since these actions do not involve the rule expression.

• "Test Rules" button: Hidden (the team admin cannot see the rules, so testing them is not meaningful in this view).

• "Delete Policy" control: Follows existing spec logic (disabled if channels > 0, enabled if channels = 0).

Save Behavior when access rules are hidden: When saving a policy where only the name or channel assignments have changed, the server must bypass operator validation on the stored rule expression.

Rule Suppression Uniformity: Rule suppression applies uniformly to all team admins regardless of authorship. While the original author may recall the rule values, uniform suppression prevents stale knowledge from being re-confirmed through the UI and simplifies the implementation.

Open

Handling Pre-Existing CEL Rules After CEL Editor Restriction NEW

When a System Admin disables the "Allow team and channel admins to use the advanced rule editor (CEL based)" setting, pre-existing team policies that were authored using the CEL editor enter a CEL-restricted state. This is distinct from the operator-restriction degraded state.

Behavior: The policy opens in the Policy Editor with the following adjustments:

• The Simple/Advanced toggle is hidden (since the CEL editor is disabled).

• If the existing policy's rule expression was authored in CEL and can be represented in Simple mode (i.e., it uses only simple attribute-operator-value conditions with AND logic), it is automatically rendered in the Simple rule builder. The admin can edit normally.

• If the existing policy's rule expression was authored in CEL and cannot be represented in Simple mode (e.g., it uses OR logic, nested expressions, or complex CEL functions), the Access Rules section is suppressed with an informational banner: Heading: "Rules use the advanced editor". Body Text: "This policy was created using the advanced rule editor (CEL), which is no longer available in your configuration. Only a System Admin can update these rules. Contact your System Admin to modify this policy's rules."

• In the suppressed state, the rest of the policy (name, channels, auto-add) remains editable.

• The "Test Rules" button is hidden when rules are suppressed, but remains available if the rule was successfully converted to Simple mode.

Save Behavior: Same pattern as operator-restriction degraded policies -- the server bypasses CEL-mode validation when only the name or channel assignments have changed.

Open

Add-Channels Modal

• Purpose: Allows the Team Admin to select which team channels to attach to the policy (in create or edit flows).

• Invocation: Triggered by clicking "Add Channels" in the Policy Editor. Opens as a modal dialog titled "Add Channels to Policy".

• Channel List: Display a scrollable list of all eligible channels in the team, similar to how we have it in the system console.

Open

Test Access Rules

• Purpose: Allows the admin to preview the outcome of the policy's rule criteria against user attributes before applying.

• Invocation: Clicking "Test Rules" in the Policy Editor opens a Test Access Rules modal.

Open

Save, Confirm, Apply

• Saving Changes: When the Team Admin clicks "Save" in the Policy Editor (for create or edit), the system will validate and then proceed to apply the changes immediately. If the policy modification affects channel memberships, a Confirmation step appears before final apply. The confirmation modal has Confirm and Cancel. Cancel returns to the editor so the admin can adjust. Confirm proceeds to apply the policy changes.

• Applying Policy: On confirm, the changes are saved to the server and membership changes are executed.

• The Team Settings modal state returns to the main Membership Policies list. The list now reflects the updated policy and channel counts.

• Any channels affected will now enforce the new rules. Users removed by the policy lose access to those channels as soon as the sync finished, and users added (with auto-sync) gain access.

Delete Policy

• Deletion Restrictions: An access policy can only be deleted if zero channels are currently assigned to it. If any channels are linked, the Delete action is disabled. In the Policy Edit page, if channels > 0, disable the Delete control with the messaging "Unassign all channels from this policy before deleting".

• Delete Action: If a policy has 0 channels, the Team Admin may delete it. The Delete option triggers a confirmation dialog: "Delete Policy [name]? This action cannot be undone." On confirm, the policy is removed from the system. A toast confirms deletion success.

• Edge Case: If a Team Admin removes all channels from a policy but does not delete it, the policy will remain in the list (with 0 channels). It can be later edited or assigned to channels, or deleted. Such a policy still counts towards their team's policy list but has no immediate effect until used. It will also be available and visible in the system console, but it should not be available and visible in the team level policies for another team.

EXCLUDED FROM MVP NICE-TO-HAVE

View System Policy (Locked View in Team Settings)

When a Team Admin selects a policy that is managed at the system level (marked "System Policy"), a read-only view is presented. This view is similar in layout to the Policy Editor but with key restrictions to prevent attribute value leakage:

• Banner: At the top, display an informational banner with a lock icon: "Access policy is managed by a System Administrator. This policy can only be edited by a System Admin because it applies to channels across multiple teams."

• The Name field is read-only (disabled).

• UPDATED Access Rules section -- Rule Suppression: The rules section does not display the rule table (Simple mode) or CEL expression (Advanced mode). Instead, it shows an informational state. Icon: Lock icon. Heading: "Access rules are restricted". Body Text: "Access rules can only be viewed or edited by a System Administrator"

• UPDATED The "Test Rules" button is removed from this view. Since the team admin cannot see the rules, testing them is not meaningful.

• Assigned Channels: This section lists only the channels in the current team that are governed by the policy. (Channels from other teams under this policy are not shown here, since a Team Admin should not see other teams' channel names. Instead, show a note above the list: "Channels from other teams assigned to this policy are hidden from this view.") The list of this team's channels is displayed with their auto-add status indicated. No Add or Remove controls are present (the Team Admin cannot modify channel assignments for a system policy).

Open

Scoping Rules & Constraints

Team-Scoped Data Only

Team Admins will only see members and channels belonging to their team in all pickers, lists, and test results. The UI and backend will ensure that a team admin cannot somehow reference or manage channels/users from outside their team's scope. For example, the "Add Channels" modal will only list channels in the current team (filtered to private channels as explained below), and the "Test Rules" function will only evaluate users who are members of that team (ignoring users on other teams).

Self Inclusion Check

Team Admins can only view, create, or modify Membership Policies for which they themselves satisfy the access rule criteria. This check is enforced at two points: (1) At load time, any existing policy whose criteria exclude the Team Admin (based on their attributes) is not visible or accessible to that admin in the Team Settings > Membership Policies tab. (2) At save time, when a Team Admin is creating or editing a policy, if their own user attributes do not satisfy the rule they are defining, the system must prevent saving and show an error (see Self-Exclusion Error under Validation Logic).

Value autocomplete

The autocomplete for attribute values must only suggest values the current Team or Channel admin holds. Non-matching values should not be suggested and they should be rejected on save by server-side validation even when they are typed in manually. Additionally, "Save" and "Test access rules" should also be prevented when the admin setting up the policy does not match the access expression they have set up.

Server-side validation behavior: When the restriction is enabled and a team admin submits a policy (via save or test) containing a disallowed operator, the server must reject the request and return a structured error identifying the disallowed operator. The UI must surface this as an actionable inline error:

• In the Simple editor: highlight the offending rule row with inline error text.

• In the CEL editor (if enabled): underline the offending operator token with a tooltip.

• Error message: "The operator [operator] is not permitted for team and channel admins. Use 'is' (equals) for exact-match rules."

• Validation occurs both on-the-fly during editing (for immediate feedback) and on save (as the authoritative check).

Error precedence: Errors are surfaced one at a time in a fixed order. If a rule violates both operator restrictions and self-inclusion, only the operator restriction error is shown first. The self-inclusion error is surfaced only after the operator issue has been corrected. This one-at-a-time precedence applies consistently during both on-the-fly editing validation and save-time validation.

Channel Type Constraints

Only Private channels can be governed by Membership Policies, per ABAC's fundamental scope.

Validation, Errors and Guardrails

Open

• Rule Completion: In Simple mode, every rule row must have an attribute and a value selected. Incomplete rows get an inline error. The admin must remove or complete any blank rule rows.

• Advanced Syntax: When in Advanced mode (CEL editor enabled), validate the CEL expression syntax on the fly. If the expression is invalid or cannot be parsed, show an error message and do not allow saving.

• NEW Operator Restriction Validation: When "Operators allowed for team and channel admins" is set to "Exact-match only", validation must check for disallowed operators in both Simple and Advanced modes. In Simple mode, the operator dropdown is pre-filtered so this is primarily a server-side safety net. In Advanced (CEL) mode (when enabled), the server must parse the expression and reject any disallowed operators, surfacing the error inline with the offending token highlighted. See the Operator Restriction for Team and Channel Admins section for error message details and precedence rules.

• License/Permission Checks: The UI should defensively check that the feature is enabled. If for some reason the admin tries an action without proper licensing or permissions (e.g. via URL manipulation), show a generic error "Membership Policies feature not enabled or not permitted."

• Channel Type Enforcement: Do not allow adding channels that are not private. The Add-Channels modal should simply not list ineligible types.

• Unsaved Changes: If the admin attempts to close the Team Settings modal or navigate away with unsaved changes, prompt "You have unsaved changes to this policy. Discard changes?" with Cancel/Discard options.

• Field Limits: Enforce any length/format limits (e.g. name length, allowed characters for names, etc.). Provide inline error for violations (e.g. "Name is too long").

• System Errors: Any unexpected server error (network failure, etc.) during save or delete should result in a non-destructive error message to the admin (toast or inline) like "Unable to save changes, please try again." The policy editor remains open so they can retry.

• NEW Mid-Edit Configuration Change: If the exact-match restriction or CEL editor availability is changed by a System Admin while a team admin has the policy editor open, the next save attempt will be rejected by the server with a validation error. The client must preserve all form edits, highlight the offending rule rows, and display the restriction error. The admin can then adjust their rules or revert to the last saved state.

System Console UI UPDATED

Visibility

The Membership Policies interface is only accessible to Team Admins (and System Admins) for a given team. Regular team members do not see the Team Settings modal at all, and thus cannot view or manage policies.

We need to add a new setting to Permissions > System Scheme > Team admins to “Manage channel membership policies”. Only if this is enabled should team admins be able to create and edit membership policies.

Open

Note: If ABAC is globally disabled by the System Admin via System Console settings, the Membership Policies tab will be hidden and inactive. The team-level UI only appears when: (1) the server has Enterprise Advanced OR Entry, (2) the global "Enable attribute-based access control" setting is ON, and (3) the "Manage channel membership policies" permission is enabled in the System Scheme for Team Admins.

A new column in the Access Policies list showing the policy type and the teams it applies to. If a policy applies to multiple teams, only the number of teams will be shown.

Advanced Configuration

This section giving system admins control over what team and channel admins should be able to do while creating polices and rules. The section contains two independent settings:

• Operators allowed for team and channel admins -- Radio selection with two options: "Exact-match only" (default) and "All standard operators". Exact-match only restricts team and channel admins to the "is" (equals) operator when creating rules, which is the safer option for sensitive attributes. All standard operators lets admins use operators like is not, in, contains, starts with, and ends with.

• Allow team and channel admins to use the advanced rule editor (CEL) -- Radio selection with True / False (default: False). When disabled, team and channel admins can only use the simple rule builder. Enable this to allow the advanced CEL editor for rule creation.

Open

Note: The two advanced configuration settings operate independently.

Removed from System Console:

• UPDATED "Allow access policy management in Team Settings" -- This is now controlled via the System Permission Scheme as a "Manage channel membership policies" permission for Team Admins, rather than a System Console toggle.

• UPDATED "Allowed operators for Team admins" multi-select -- Replaced by the "Operators allowed for team and channel admins" setting above.

Warning Modal: Switching to "All standard operators" NEW

When a System Admin changes "Operators allowed for team and channel admins" from "Exact-match only" to "All standard operators", show a warning modal before applying the change:

• Type: Warning modal in System Console, shown before saving the configuration change.

• Title: "Allow all standard operators?"

• Message: "Allowing all standard operators means team and channel admins can use operators like contains, starts with, and in when creating access rules. These operators can reveal sensitive attribute values to admins who may not hold those values themselves. For example, an admin could use contains to test partial values and discover the full attribute values assigned to other users. Only allow all standard operators if the attribute values in your organization are not sensitive or confidential."

• Actions: "Confirm" to proceed with enabling all operators, "Cancel" to keep the setting on "Exact-match only."

Open

Warning Modal: Restricting Operators or CEL Editor (Unified) UPDATED

When a System Admin tightens either restriction -- changing "Operators allowed for team and channel admins" from "All standard operators" to "Exact-match only", or changing "Allow team and channel admins to use the advanced rule editor (CEL)" from True to False -- and pre-existing team/channel policies would be affected (i.e., policies use now-restricted operators or non-convertible CEL expressions), show a single unified warning modal upon save:

• Type: Warning modal in System Console, shown after saving the restriction change.

• Title: "Some policies will be affected"

• Message: "Team and channel admins will no longer be able to view or edit the rules in the affected policies. Only a System Admin can modify these policies' rules from the System Console."

• Actions: "Confirm" to proceed, "Cancel" to revert the toggle change.

Note: This unified modal replaces the previously separate notification modals for operator restriction and CEL editor restriction. The same modal is used regardless of which restriction is being tightened, since the impact on team and channel admins is identical in both cases -- they lose visibility and edit access to the affected rules.

Open

Assumptions and Open Questions

During design and development of Team-Level Membership Policies, a few assumptions were made, and some questions remain to be clarified or confirmed:

• Team Admin Permissions: We assume that Team Admins have the necessary permissions to remove users from any private channel in their team via this feature, even if they themselves are not members of that channel. Normally only channel members (or sysadmins) can manage a channel's membership. However, since this is an admin-level operation and channel membership changes are executed by the system, we presume it is allowed.

• Orphan Channels: If a channel becomes empty due to policy, how will any admin know or manage it afterwards? If informed, an admin can possibly choose to intervene. We allow orphan channels because maybe they intentionally want it empty until someone qualifies in future (like waiting for a new hire with that attribute). We assume that is acceptable, but it is an odd state. That might warrant a future improvement (e.g., auto-archive empty channels?). But out-of-scope now. We will document that as an admin consideration.

• NEW Attribute Value Confidentiality: We assume that in defense and regulated environments, attribute values (program names, clearance levels, organizational designators) are themselves controlled information. The default-restricted posture reflects this assumption. Organizations where attribute values are non-sensitive can disable the restriction.

• NEW Uniform Rule Suppression: Rule suppression applies uniformly to all team admins regardless of whether they authored the policy. This is a deliberate simplification -- tracking per-user authorship for conditional visibility adds implementation complexity with marginal security gain, as attribute values may have been rotated since the policy was authored.

• NEW CEL-to-Simple Conversion: We assume the server can detect whether a CEL expression is representable in Simple mode (attribute-operator-value conditions with AND logic only). Expressions using OR logic, nested conditions, or CEL-specific functions are treated as non-convertible and suppressed when the CEL editor is disabled.

Decision Log NEW

See also

Below are some other related links that are supplemental to this feature:

• Channel Admin ABAC Controls

• System Admin ABAC Controls