Corpus permissions in Ejento AI decide who can view a corpus, who can change its content and settings, and who can delete it or share it further. Access can be granted to individual users or to entire teams, and it always works together with your organization's Permission Sets.Why corpus permissions matter#
A corpus is often the most sensitive part of an assistant: it holds the actual documents, policies, and data the assistant answers from. Clear permissions let you:Share knowledge without oversharing. Give a sales team read-only access to product sheets while only product managers can edit them.
Delegate maintenance. Let content owners keep a corpus up to date without involving an administrator every time.
Manage access at scale. Grant access to a team once; people who join or leave the team gain or lose access automatically.
Keep governance consistent. Organization-wide Permission Sets put an upper limit on what any individual share can unlock.
Changed: corpus roles are now Member and Admin. The previous Viewer role is now Member (renamed only). The previous Editor role was merged into Admin, which can also delete a corpus and manage who has access, if the user's Permission Sets allow those actions. Admin and Owner are unchanged. Review former Editor shares if that isn't what you intend.
How access works: two layers#
1.
Permission Sets are organization-wide, reusable rules. They decide which actions a user can perform on corpora at all, and how widely those actions reach.
2.
Corpus roles are granted per corpus from the Corpus Settings window. They decide which corpus a user may act on.
Roles#
| Role | What it allows |
|---|
| Member | View the corpus, its documents, sitemaps, conversation starters, and connected agents. No changes. |
| Admin | Everything a Member can do, plus: edit corpus details, upload and delete documents, manage sitemaps, trigger re-indexing, annotate, delete the corpus, and manage access (grant, update, and revoke access for users or teams). |
| Owner | The person who created the corpus. Same as Admin, but can't be removed or changed. |
Managing access is an Admin and Owner action. Members can't change who has access.
The creator is always the Owner#
The user who creates a corpus is automatically its Owner. This can't be changed or revoked in the app, so every corpus always has an accountable owner.Team access stays in sync#
Granting a role to a team applies it to all current members of that team. When users are added to or removed from the team, their corpus access updates automatically, with no manual re-granting.Choosing the right role#
Give Member to people whose assistants need the knowledge, or who need to browse it, but who shouldn't change it.
Give Admin to the people who maintain the corpus: content owners, subject-matter experts, and their backups.
Keep the number of Admins small for sensitive corpora, and prefer team grants over many individual grants so access is easier to review.
Permission Sets and corpora#
Corpora are governed by Permission Sets, alongside assistants and workflows. For corpora, a Permission Set defines three scoped actions plus a create toggle:| Action | What it allows |
|---|
| View | View the corpus, its documents, sitemaps, conversation starters, and connected agents. |
| Edit | Everything under View, plus edit corpus details, upload and delete documents, manage sitemaps, trigger re-indexing and annotate, and manage corpus access. |
| Delete | Delete corpora within scope. |
| Create | Whether the user may create new corpora at all. |
Scopes available to corpora#
A corpus belongs to the organization, not to a project, so its scopes are narrower than an assistant's:| Scope | Grants the action on… |
|---|
| All | Every corpus in the organization (broadest). |
| Teams | Corpora the user's teams have access to. |
| Own | Only corpora the user created (narrowest). |
Unlike assistants and workflows, corpora have no project scope (no "corpora in the projects they have access to" option) and no deploy or publish action, because corpora are never published.
How corpus roles map onto Permission Sets#
| Corpus role | Permission Set tier | What it can unlock |
|---|
| Member | member | View only. |
| Admin | admin | View, edit, and delete, each only if the user's Permission Sets grant that action. |
| Owner | — | Not a share tier. Ownership is what the Own scope resolves against; it can't be transferred or revoked. |
How access resolves#
A corpus role doesn't grant actions by itself. It names which corpus a user may act on; the actions still come from their Permission Sets:Member: the user can view the corpus if they hold any Permission Set granting corpus view at any scope. A Member role adds nothing to edit or delete.
Admin: the user can view, edit, or delete the corpus, action by action, if they hold a Permission Set granting that same action at any scope. Being made an Admin never unlocks an action their Permission Sets don't grant, so a former Editor without corpus delete permission still can't delete it.
Team grants are checked at team scope.
Public corpora are shared with everyone in the organization at Member (view-only) level; each user still needs their own view permission.
Creating corpora is also controlled. A user without a Permission Set that has the corpora Create toggle turned on can't create a corpus, even if they can view and edit existing ones.
Use cases#
Sales playbook: The sales enablement lead creates a "Sales Playbook" corpus, so they're the Owner. Two enablement managers are Admins who upload new battlecards each month. The whole Sales team has Member access through a team grant, so every rep's assistant can use the playbook, and new hires get access the moment they join the team.Confidential HR content: Keep an "Employee Records" corpus to a small set of HR Admins, with no team grants, so access is easy to review. 