Permission Sets are how Ejento AI controls who can see and do what inside your organization. Instead of granting access to each user one resource at a time, you define a reusable Permission Set once — a named bundle of access rules — and then assign it to the people who need it. Every user attached to that set inherits exactly the access it defines, and any later change to the set applies to all of them at once.A Permission Set covers the three kinds of resource Ejento AI governs: assistants, corpora, and workflows. Each is configured separately inside the same set, so one set can, for example, grant wide access to assistants while keeping corpora locked down to the ones the user owns.Each resource in a Permission Set is built from scopes. A scope answers the following questions:
View scope — which resources the user is allowed to see.
Edit scope — which resources the user is allowed to modify.
Delete scope — which resources the user is allowed to remove.
Deploy scope — which assistants the user is allowed to deploy changes to production. (Assistants only — corpora and workflows are not deployed).
There is also a Create toggle per resource, which decides whether the user may create new assistants, corpora, or workflows at all.
The three resources do not offer identical options, because they sit differently in the product:
Resource
Actions you can scope
Scopes available
Create toggle
Assistants
View, Edit, Delete, Deploy
All / Projects / Teams / Own
Yes
Corpora
View, Edit, Delete
All / Teams / Own — no project scope
Yes
Workflows
View, Edit, Delete
All / Projects / Teams / Own
Yes
A corpus belongs to the organization rather than to a project, so there is no "corpora in the projects they have access to" option. Corpora and workflows are never deployed, so neither has a Deploy scope.
Each of the view, edit, delete, and deploy actions is assigned a scope.
Scope
Grants the action on…
All
Every resource of that kind in the organization (broadest).
In the projects they have access to
Resources belonging to projects the member can access. Assistants and workflows only.
Their teams have access to
Resources the user’s team(s) can access.
They own
Only the resources the member owns (narrowest). The creator of a corpus or workflow is its owner.
Scopes are usually narrowed to a boundary like "the ones they own", so a user can manage their own resources without touching anyone else's. Sensitive actions — most notably deploying changes to a live assistant — are gated separately, so a user may be able to edit a configuration but still be prevented from pushing it to production until an administrator approves.
Ejento AI controls access through two complementary layers. Understanding the difference is key to setting people up correctly.
1.
Account roles — a broad tier assigned to each person that sets their baseline reach across the organization.
2.
Permission Sets — fine-grained, reusable rules layered on top of a role that decide exactly what a person can create, view, edit, delete, and deploy for which specific assistants, corpora, and workflows.
A useful way to think about it: roles decide how far someone's authority extends; Permission Sets decide exactly what they can touch within each resource.
Full control: manage all users, teams, projects, assistants, corpora, and workflows; configure organization settings; create and assign Permission Sets. This is the highest level of access.
Application Admin
Application-level functions and resources
Elevated administrative access over many areas and shared resources, but without full organization-admin authority. Sits below a Global Admin.
User
Only the resources they own or are granted
Works within their own assistants, projects, corpora, and workflows, plus anything explicitly shared with them.
Note: On any individual resource (a specific assistant, corpus, workflow, team, or project), a user can additionally hold an Admin or Member access, which further refines what they can do with that one item — independent of their org-wide role.
Roles set the ceiling; Permission Sets carve out the precise access beneath it. Assigning someone the "User" role doesn't, by itself, say what they can do to which assistants, corpora, or workflows — the Permission Sets you attach to them do.
High-impact actions stay gated. Even a user who can edit a configuration may be blocked from deploying it to a live environment.
In short: use roles to establish broad trust levels (who is an admin vs. a regular user), and use Permission Sets to precisely define what each user can see and change within assistants, corpora, and workflows.
Permission Sets grant scoped access across whole populations of resources, but an individual assistant, corpus, or workflow can also be shared directly with a user or a team — and assistants and corpora can be shared with every user in the organization at once by making them Public.A direct share does not grant actions by itself. It names which resource a user may act on; the actions they can actually perform still come entirely from the Permission Sets they hold. In other words, a share opens the door to a specific resource, but the Permission Set decides what the user can do once inside.
What it can unlock (given a matching Permission Set)
member
View only.
admin
View, edit, delete — plus deploy for assistants, and permission management for corpora and workflows.
Each resource's own share roles map onto those two levels:
Resource
Shows up as "member"
Shows up as "admin"
Can be made Public?
Assistants
Member
Admin
Yes
Corpora
Member (was Viewer)
Admin (was Editor or Admin)
Yes
Workflows
Member
Admin
No
Changed: corpus roles are now Member and Admin
Corpus sharing used to offer Viewer, Editor, and Admin. It now offers Member and Admin, matching assistants and workflows — Viewer was renamed to Member, and Editor was merged into Admin (an Editor could only edit, but delete or re-share a corpus).Existing shares are migrated: Former Viewers are Members, former Editors are Admins, and Owners are unchanged. The one thing worth reviewing is that a former Editor now sits in the tier that can also delete a corpus — which they can do only if their Permission Set grants corpus delete.
The Owner of a corpus or workflow is not a share level. Ownership is what the "they own" scope resolves against, and it cannot be transferred or revoked from the permissions panel.
For each action, a directly-shared user's access is the intersection of their share level with their capability for that action.A capability is the scope-agnostic union of every scope grant the user holds for that action across all of their assigned Permission Sets — in plain terms, "does this user have view (or edit, delete, deploy) on this kind of resource at any scope?"
Member share — the user can view the resource if they hold any Permission Set that grants view on that resource at any scope. A member share contributes nothing to edit, delete, or deploy.
Admin share — the user can view, edit, or delete the resource, action by action, if they hold any Permission Set that grants that same action on that resource at any scope. An admin share never unlocks an action the user has no Permission Set for.
This is resolved per resource kind. A Permission Set that grants sweeping assistant access does nothing for a corpus share, and vice versa.
Public assistants and corpora are shared with all users in the organization at once, at member access. Every user then resolves against their own view capability individually — so only members who already hold view somewhere gain access. Making a resource Public does not override the Permission Set requirement; it simply extends a member-level share to everyone. Workflows cannot be made public.
Note — team shares differ: A direct share to a team behaves slightly differently — it is gated at team scope rather than by the scope-agnostic capability. The capability-based resolution described above applies to shares made directly to an individual user.
Key takeaway: a share (direct or Public) answers "which resource?"; the user's Permission Sets answer "which actions?" Access is only granted where the two overlap.
Not every Permission Set behaves the same way. Two special categories carry rules you can't override, and there are a few organization-wide limits worth knowing before you start creating sets.
A default Permission Set is one that is automatically assigned to every new user added to the organization, so people start with a baseline of access from day one. Because of this, defaults follow special rules:
An organization must always have at least one default Permission Set.
The last remaining default cannot have its default field toggled off — this guarantees the organization is never left without a default. (Once another set is marked default, the previous one can be freely toggled again.)
Turning a set's default on or off changes only future assignments to new users; it doesn't retroactively add or remove the set from existing users.
A user can have at most 20 Permission Sets assigned at any one time. Plan for this ceiling when designing sets — favor a smaller number of well-scoped sets over many narrow ones.
Quick reference
Rule
Detail
System sets
Scopes are locked; only the default toggle and user assignments can change.
Minimum defaults
At least one default must always exist in the organization.
Last default
Its default field cannot be toggled off while it's the only default.
New users
All default sets are auto-assigned to every new user.
