BeforeQuery has three permission layers: workspace roles, knowledge-base-level permissions, and document visibility. Together they control who can administer the workspace, which knowledge bases someone can ask questions against, and which documents each audience can see.

​
Workspace roles

Every workspace member has one of four roles: Assign roles when inviting members, or change them later from Workspace → Team. user is the chat-only role: it can ask questions in the knowledge bases you share with it and nothing else. Editing permissions are never grantable to it, so a stray toggle can’t promote a chat-only account.

​
Knowledge base permissions

Grants are managed under Knowledge Base → Permissions, one row per person, with four capabilities: Owners and admins hold every capability on every knowledge base, and grants aren’t consulted for them. Members hold each capability only where it’s been explicitly granted. Users can only ever hold chat. The Ask section shows each person exactly the knowledge bases they may chat with — and a multi-knowledge-base question is scoped to that same set, intersected rather than unioned, so naming a knowledge base you can’t reach silently drops it instead of widening your access.
Ask access spans every workspace you belong to, not just the one you’re currently viewing.
Internal Ask access is not gated by any public-portal setting — it follows these permission rules only.

​
Document visibility

Each indexed document is public or restricted: Use restricted for internal runbooks, pricing playbooks, or pre-release docs you want your team — but not your customers — to get answers from. Toggle a document’s visibility from its page under Knowledge Base → Documents, or re-label everything one source indexed at once from the source’s page.
Bots are on the internal side of this line. A Slack, Discord, or Teams bot answers inside a workspace you installed it into, so it retrieves restricted documents just as a member does — and there’s no per-user check, so everyone in the channel sees the same answers. Treat connecting a bot to a channel as publishing that knowledge to everyone in it.
Visibility is set when a document is first created and never changed by a later sync, so a value you set by hand survives every re-sync. That also means changing a source’s default only affects documents indexed from then on — use the source’s bulk re-label to catch up the existing ones. For a knowledge base that should have no public face at all, set its type to internal rather than restricting documents one by one — see Knowledge Bases.

​
Scoping external access

For traffic outside your team (widget, SDKs, public API), access is governed by client keys, not roles: keys can be limited to specific source groups via allowed_groups, and requests can narrow retrieval further with group_ids (never widen). See Authentication.