Invite members & roles
Who can do what: admins vs members vs project owners / editors / viewers.
Two role levels
Knowledge has two completely separate permission systems that work together:
- Workspace role — applies to the whole workspace. Admin or member.
- Project role — applies to one project. Owner, editor, or viewer.
A user can be a workspace member with no projects (sees nothing), or a member who is owner of one project and viewer of two others (sees only those three).
Workspace roles in detail
| Action | Admin | Member |
|---|---|---|
| Sign in to the workspace | ✓ | ✓ |
| See all projects, even ones they're not a member of | ✓ | — |
| Create / delete projects | ✓ | — |
| Invite / remove members | ✓ | — |
| Promote members to admin | ✓ | — |
| Create / edit / delete agents, mint agent keys | ✓ | — |
| Change plan, manage billing | ✓ | — |
| Search / chat / upload within projects they belong to | ✓ | ✓ |
| Run agents (browser, Word, Excel, API) on projects they belong to | ✓ | ✓ |
Project roles in detail
| Action | Owner | Editor | Viewer |
|---|---|---|---|
| See documents in the project | ✓ | ✓ | ✓ |
| Search / chat scoped to the project | ✓ | ✓ | ✓ |
| Upload new documents to the project | ✓ | ✓ | — |
| Delete documents from the project | ✓ | ✓ | — |
| Add or remove project members | ✓ | — | — |
| Change other members' roles in the project | ✓ | — | — |
| Delete the project | (admin only) | — | — |
Inviting someone
You must be an admin. Account popover → Members → + Invite.
- Type their work email. If they already exist in your Entra / Azure AD tenant, sign-in works the first time they visit Knowledge — no further step.
- Pick their workspace role: member (default) or admin. Be conservative with admin — only people who need to manage billing or agents.
- (Optional) Pre-add them to specific projects with specific project roles. Skip this if you want to assign per-project access later.
- Click Send invite. They get an email with a one-click sign-in link.
External guests (people outside your Microsoft tenant) can be invited too, if the workspace setting Allow external guest collaboration is on. This is off by default — admins can toggle it under Settings → Workspace.
Changing someone's role
Workspace role (admin / member): account popover → Members → click the role badge next to their name → pick the new role.
Project role (owner / editor / viewer): either the workspace admin or the project owner can change it.
- From the project: Projects → open project → Members → change role per row.
- From the member: Members → open user → table of their project memberships → change role per row.
Removing someone
Members → open user → Remove from workspace. Cascade:
- Their session is invalidated on the next request.
- They're removed from every project they were a member of.
- Threads they started stay in the database (so audit trails are intact) but no longer appear in anyone's "Recent" list.
- Documents they uploaded stay in the projects they uploaded them to — they belong to the project, not the uploader.
- Agent keys they minted stay active (keys are workspace-scoped, not user-scoped). Rotate keys if the departure is sensitive.
Honest design notes
- Promoting all members to admin "to make life easier" is a real lie — once it's done, every member can change plan and mint agent keys. Keep admin small (1-3 people for a 20-person workspace is typical).
- Project owners can't delete projects. Only workspace admins can. This is intentional — losing a project loses every document linked to it, so the action sits one level up.
- There's no read-only-everything workspace role. If you want a person to see all projects in read mode (for audit), add them as viewer on each project explicitly. Yes this is tedious for many projects; a true "auditor" role is on the roadmap.