Three settings decide who can do what: a person’s workspace role, their knowledge base permissions, and each document’s visibility.
Workspace roles
Everyone in a workspace has one role.
| Can | Owner | Admin | Member | User |
|---|
| Delete the workspace, transfer ownership (API only) | ✓ | — | — | — |
| Manage the team, billing, usage, SSO, API keys, AI model and workspace settings | ✓ | ✓ | — | — |
| Manage integrations: widgets, bots, helpdesks, form deflectors, agent apps, customizations | ✓ | ✓ | — | — |
| Grant knowledge base permissions | ✓ | ✓ | — | — |
| Create knowledge bases | ✓ | ✓ | ✓ | — |
| View and edit a knowledge base | All | All | Where granted | — |
| Ask questions | All | All | See below | See below |
| Use the dashboard | ✓ | ✓ | ✓ | Ask only |
- Owner and admin can do everything on every knowledge base. Grants do not apply to them.
- Member can create knowledge bases, but views or edits one only where granted.
- User is chat-only. The only grant a user can hold is Chat.
Set the role when you invite someone, or later from Team → Members → Edit access.
Knowledge base permissions
Owners and admins set grants in two places: Team → Members → Edit access (one person, every knowledge base) and a knowledge base’s Permissions tab (one knowledge base, every person).
| Grant | Lets them |
|---|
| View | See the knowledge base, its sources and documents in the dashboard |
| Edit Sources (Sources on the Team page) | Add, edit, sync and delete sources and source groups; write custom answers; accept Knowledge Maintenance drafts; save web clips |
| Edit Config (Config on the Team page) | Change settings and the sync schedule; manage client keys and MCP servers; archive, restore or delete the knowledge base |
| Chat | Ask questions in it from Ask, the browser extension and Internal MCP servers |
- Edit Sources and Edit Config switch on View too.
- A member who creates a knowledge base gets every permission on it.
Who can chat
By default, everyone in the workspace can ask questions in every knowledge base. Each knowledge base has a Workspace members switch under Settings → Who can reach this. Turn it off and only owners, admins and people with a Chat grant can ask.
Ask lists exactly the knowledge bases you may chat with. In the dashboard that is the current workspace; the browser extension and the internal MCP server cover every workspace you belong to.
Document visibility
Every document is public or restricted.
| Where the question is asked | public | restricted |
|---|
| Widget, form deflector, public API and SDKs | ✓ | — |
| API key and Public MCP servers | ✓ | — |
| Helpdesk automation replies, and drafted replies in the agent sidebar | ✓ | — |
| Ask, the browser extension and Internal MCP servers | ✓ | ✓ |
| Agent sidebar chat and internal notes | ✓ | ✓ |
| Slack and Teams bots | ✓ | ✓ |
restricted for runbooks, internal playbooks or pre-release docs that your team should get answers from and your customers should not.
A document’s visibility is set when it is first indexed. A later sync never makes a document public. The one change a sync makes is the other way: a Salesforce Knowledge article that is not on a public channel is switched to restricted. To set it:
- When you add a source: set Visibility to Restricted in the Add source form. Everything the source indexes, starting with its first sync, is restricted.
- For a source you already have: on the source’s Configuration tab, under Indexing, set New documents to Restricted. It applies only to documents indexed after you save. To relabel what it has already indexed, use the call below.
- For everything a source has indexed:
PATCH /api/v1/sources/:id/documents/visibility with {"visibility": "restricted"}.
- For one document:
PATCH /api/v1/documents/:id with the same body.
- For a whole knowledge base: make it internal. Every document it indexes is restricted.
Bots see restricted documents. A Slack or Teams bot answers everyone in the channel with no per-person check, so connecting one publishes that knowledge to the whole channel.
Access from outside the workspace
The widget, SDKs and public API use client keys, not roles. A key belongs to one knowledge base and can be limited to your domains. See Authentication. 
