Capabilities

What is a Capability?

A capability is an access rule: a named description of a slice of your conversations, plus how hard that description bites.

It answers "which tickets is this person for", separately from "what is this person allowed to do in the app". The second one is the user's role (User, Admin). Capabilities never change what someone may click; they change which conversations exist for them.

An agent with no capabilities sees and can be served everything. Rules only ever start mattering once you add them.

They live in three places:

• Settings → Capabilities, the shared library. A rule here can be reused across users and squads.
• Settings → User Management, where you attach library rules to one person and can give them a private rule of their own.
• Settings → Squads, where a squad carries rules describing the slice that squad covers.

The four dimensions

Every rule describes conversations along four axes. Leave one empty and it means "all".

• Markets 🌍 which markets the conversations belong to.
• Channels 💬 email, chat, phone, social, review.
• Tags 🏷️ only conversations carrying one of these tags.
• Excluded tags ⛔ conversations carrying one of these are out, whatever else matches.

Inside one rule the dimensions are combined with AND: "Danish market and chat" means Danish chats, nothing else.

Note: tags are matched strictly. A rule that lists tags matches only conversations that actually carry one of them, so an untagged ticket is outside the slice. That is the single most common surprise: a tag-restricted agent sees far less than expected because most new tickets are not tagged yet.

Enforcement: how hard a rule bites 🔒

Each rule carries one of three modes. This is the part worth understanding, because the same slice behaves completely differently depending on which one you pick.

• Strict 🔒 Enforced everywhere. Conversations outside the slice are hidden from the board, left out of the sidebar counts, and never served. Use it when the restriction is a real boundary, for example a compliance or language wall.
• Routing 🎯 Limits automation only. The board stays fully visible and anyone can still claim anything by hand, but flow mode and automatic assignment only serve conversations inside the slice. Use it for "these people normally take phone" without walling anything off.
• Preference ⭐ Priority only. Nothing is hidden, nothing is blocked. Flow mode serves the slice first and falls back to the rest of the queue once it is empty. Use it for soft specialisation.

Excluded tags follow their own rule's mode: a strict exclusion hides those conversations, a routing exclusion keeps automation away from them, a preference exclusion just serves them last.

Several rules widen, they do not narrow

A person can have several rules, and their access is the union: a conversation matches them if any single rule matches it completely.

That "any single rule, completely" part matters. Someone with one rule for chat in Germany and Denmark and another for phone in Denmark does not get German phone calls. The dimensions are never mixed across rules, which is what stops access leaking through combinations you never wrote down.

So if you want to restrict someone, do not add rules until it looks right: write the one rule that describes what they should have, and use strict.

Rules on a user versus rules on a squad

This is the other thing people get wrong. Putting someone in a squad does not hide anything from them.

• The default helpdesk board is scoped by the person's own rules: the library rules attached directly to them plus their private rule. Only strict ones affect the board.
• Rules that live on a squad reach the board only when that squad is selected in the sidebar's Squads drill-down.
• For routing, both count. Deciding whether an agent may be served or assigned a conversation uses their own rules plus everything inherited from their squads.

Practical translation: use squads to describe coverage and to group people for routing, transfers and alerts. Use a strict rule on the user when you genuinely need to restrict what someone can see.

Worked examples

• Nordic agent, hard boundary: one rule, markets DK, SE, NO, mode strict. They only ever see Nordic tickets.
• Phone specialists: a squad with a rule on the phone channel, mode routing. Calls route to them, the board stays whole for everyone.
• Soft specialisation: a rule with the tag "Returns", mode preference. Flow mode gives them returns first, then anything else.
• Keep one person away from a topic: a rule with no positive dimensions at all and "Legal" in excluded tags, mode strict. Everything except that topic.

Good to know

• The Squads drill-down applies the squad's rules on top of your own access. It can never show you something your own rules do not already allow.
• A rule with every dimension empty restricts nothing. That is legitimate for an exclude-only rule, and a no-op otherwise.
• Library rules are shared: editing one changes it for every user and squad it is attached to. A private rule belongs to that one user or squad.
• A tag used by a capability cannot be deleted until the rule stops referencing it. The error names what is holding it.
• Sidebar counts are cached briefly, so a count can lag a moment behind a rule change.