Corpus permissions in Ejento AI define the actions users can perform on a corpus, including viewing, editing, and managing its content and settings. Access can be granted to individual users or entire teams, each assigned one of three roles.
Changed: corpus roles are now Member and Admin
Corpus sharing has moved from four roles to three, to match assistants and workflows:
Old role
New role
What it means for you
Viewer
Member
Renamed only. Read-only access is unchanged.
Editor
Admin
Merged. Editor only allowed editing, so it now sits in the Admin tier — which additionally allows deleting and re-sharing a corpus.
Admin
Admin
Unchanged.
Owner
Owner
Unchanged. Still the creator, still not removable.
Note: A former Editor is now an Admin, so they can additionally grant access and delete the corpus — provided their Permission Set grants corpus edit and delete. Review your Editor shares if that is not what you intend.
Corpus access has two layers that work together:
1.
Permission Sets — org-wide, reusable rules that decide which actions a user can perform on corpora at all, and how widely those actions reach.
2.
Corpus roles — the per-corpus roles below, granted from the corpus permissions panel, that decide which corpus a user may act on.
View the corpus, documents, sitemaps, conversation starters, and connected agents. No changes allowed.
Admin
Everything a Member can do, plus: edit corpus metadata, upload/delete documents, manage sitemaps, trigger re-indexing, annotate, delete the corpus, and manage the permissions panel (grant, update, and revoke access for users or teams).
Owner
The corpus creator. Identical to Admin but cannot be removed or changed via the permissions panel.
Permission management is an Admin/Owner action. Members cannot open the permissions panel.
Granting a role to a team applies it to all current members of that team. Adding or removing users from the team automatically updates their corpus access — no manual re-granting required.
Corpora are governed by Permission Sets alongside assistants and workflows. A Permission Set defines, for the corpora resource, 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 metadata, upload/delete documents, manage sitemaps, trigger re-indexing and annotate — and manage the corpus permissions panel.
A corpus belongs to the organization, not to a project. That makes its scopes narrower than an assistant's:
Scope
Grants the action on…
All
Every corpus in the organization (broadest).
Teams
Corpora the user's team(s) have access to.
Own
Only corpora the user created (narrowest).
Unlike assistants and workflows, corpora have no project scope — there is no "corpora in the projects they have access to" option — and no deploy/publish action, because corpora are never published.
A corpus role does not 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 contributes 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 on a corpus never unlocks an action their Permission Sets do not grant — so a former Editor who has no corpus delete permission still cannot delete it.
Team grants are gated at team scope rather than by the scope-agnostic capability.
Public corpora are shared with everyone in the organization at member (view-only) level; each user still resolves against their own view capability.
Corpus creation is also gated. A user who holds no Permission Set with the corpora Create toggle enabled cannot create a corpus, even though they may be able to view and edit existing ones.
