This guide walks through creating a Permission Set, defining its scopes, assigning users, and verifying how the resulting access behaves in the app.Who this is for: Organization administrators working in the Ejento AI Admin Panel.Where you'll be working: Organization Settings → Users & Teams → Permission Sets.
Before you begin#
Make sure you have the following ready:Administrator access to the Ejento AI Organization Settings. Only admins can create Permission Sets and assign users to them.
A clear scope in mind. Decide which permissions to grant on each resource and how broad each scope should be:Assistants — Create / View / Edit / Delete / Deploy
Corpora — Create / View / Edit / Delete
Workflows — Create / View / Edit / Delete
The list of users who will receive this Permission Set.
1. Open the Permission Sets page and add a new set#
Go to Organization Settings → Users & Teams → Permission Sets and click on Add Permission Set to open the creation form.2. Name the Permission Set#
Give the set a unique, clear, descriptive Name. Choose something that communicates the role or level of access it grants (for example, "Assistant Manager" or "Assistant Owner — Standard"), since this is what you'll pick from when assigning users later.3. Add a description.#
Enter a short Description explaining the purpose of the set and what access it is intended to provide. A good description saves future administrators from guessing, and makes audits far easier.4. Enable the permissions that you want to grant by checking the box beside the actions.#
The heart of a Permission Set. One set covers all three kinds of resource — Assistants, Corpora, and Workflows — and each is configured separately, so you can, for example, let a user see every assistant in the organization but only edit and delete the corpora they own.Check the actions you want to grant for each resource:| Resource | Actions available |
|---|
| Assistants | Create, View, Edit, Delete, Deploy |
| Corpora | Create, View, Edit, Delete |
| Workflows | Create, View, Edit, Delete |
Deploy applies to assistants only. Corpora and workflows are never deployed to production, so neither offers a Deploy permission.
| Scope | Assistants | Corpora | Workflows |
|---|
| All — every one in the organization | Yes | Yes | Yes |
| In the projects they have access to | Yes | — | Yes |
| Their teams have access to | Yes | Yes | Yes |
| They own | Yes | Yes | Yes |
Corpora have no project scope. A corpus belongs to the organization rather than to a project, so there is no "corpora in the projects they have access to" option. Corpus access comes from All, Teams, or They own — or from a direct grant on the corpus itself.
6. Enable any other action(s) required with the desired scope, for each resource.#
Repeat steps 4 and 5 for every resource this set should cover. Scopes are chosen per action and per resource, so a single set can grant wide assistant access and narrow corpus access at the same time.View is raised automatically when it would be too narrow. A user who can edit, delete, or deploy something must also be able to see it, so if you set a wider scope on one of those actions than on View, View is widened to match — for each resource independently. If the wider scopes mix Teams and Projects (neither of which includes the other), View is raised all the way to All.
7. Click on Next: Users#
8. Assign users to the Permission Set#
Select each user who should be granted this access, click Next: Review.9. Click on Create Permission Set#
When the name, description, and scopes are set, then click Create Permission Set to save.10. Confirm creation#
A "Permission set created successfully" confirmation appears. Your set now exists and is applied to every user you selected. You can revisit the Users tab at any time to add or remove members.11. Assign multiple Permission Sets to a user at once#
Go to Organization Settings → Users & Teams → Users and click on Edit Permissions against the user to assign/remove permission sets.12. Select the permission sets and click Save.#
Please note that when multiple permission sets are assigned, the user is granted the highest permission level across all of them. A user can be assigned up to 20 permission sets.
Best practices#
Follow least privilege. Grant the narrowest scope that still lets people do their job. It's easier to widen access later than to walk back an over-permissive set.
Name and describe clearly. A future administrator (or an auditor) should understand a set's purpose from its name and description alone.
Prefer "they own" scopes for Edit and Delete so users can't affect resources that aren't theirs.
Keep deployment separate. Let contributors edit and stage changes freely, but reserve deploy-to-live permission for a smaller, trusted group.
Set each resource deliberately. Assistants, corpora, and workflows are configured independently within one set. Granting broad assistant access says nothing about corpora — decide each one rather than leaving it to chance.
Remember that Edit carries sharing for corpora and workflows. Granting Edit also lets the user re-share the resource with other people, so treat it as a trust decision, not just a content one.
Watch the Create toggles. A user with no Create permission on a resource cannot make new ones at all, however wide their View and Edit scopes are.
Troubleshooting#
| Symptom | Likely cause | What to do |
|---|
| "You don't have permission to deploy these changes." | The user's Permission Set doesn't include deploy rights. | An administrator deploys the change, or grants deploy permission. |
| A user can't see a resource they expect. | The View scope is too narrow, or they aren't assigned to the set. | Widen the View scope or add the user under the set's Users tab. |
| A user can view but not edit/delete. | The Edit / Delete scope is narrower than View (by design). | Adjust the relevant scope in Edit Permissions if broader access is intended. |
| Changes to a set don't take effect. | The user may need to refresh. | Have the user reload the app; confirm the set was saved successfully. |
| A user can't create a corpus or workflow. | No assigned set enables Create for that resource. | Enable the Create permission for that resource on one of their sets. |
| A user was shared a corpus or workflow directly but still can't open it. | A share names which resource; the actions come from the Permission Set. They hold no set granting View on that resource at any scope. | Grant View on that resource in one of their sets. |
| A user shared a resource as Admin still can't delete it. | An Admin share never unlocks an action no Permission Set grants. | Grant Delete on that resource in one of their sets, at any scope. |
| A member of a shared team can view but not edit. | Team shares are gated at team scope, and a Member-level team share is capped at view. | Share with the team at Admin level, and grant Edit on resources their teams have access to. |
