Team: Users, Roles and Groups

The Team page, under Manage in the sidebar, is where you decide who can use the tenant and what each person may do. It opens for anyone holding View users; each action on it needs its own permission, and a control you cannot use is not shown.

Tab	What it holds
Users	The tenant's members and its pending invitations.
Groups	Groups of users that receive roles together.
Effective permissions	Who has access to a role, project, review step or catalog, directly or through a group.
Roles	The built-in roles and your custom roles, with their permissions. Administrators only.

How access works

Access is made of permissions (viewing transactions, approving them, editing configuration, publishing, managing users, and so on). A role is a named bundle of permissions, and a person gets a role through a role assignment:

• A project role applies in one project. Designer, Supervisor, Reviewer and Front Office Operator are always assigned per project.
• A tenant-wide role applies everywhere in the tenant. Admin and Security Auditor are always tenant-wide; User Manager can be either.

A person can hold several roles, in several projects. What they can do is everything those roles allow together.

Built-in roles

Role	Scope	For
Admin	Tenant	Full control of the tenant: users and roles, projects, models, licensing, security.
User Manager	Tenant or project	Inviting, creating and removing users, and assigning the non-administrative roles, within the projects it manages.
Designer	Project	Building the project: document types, fields, rules, workflow, publishing; also processing and reviewing.
Supervisor	Project	Running the work: every transaction in the project, assigning and prioritising work, reviewing at every step.
Reviewer	Project	Reviewing and correcting transactions, at every review step or only the steps chosen in the assignment.
Front Office Operator	Project	Submitting documents and handling their own transactions.
Security Auditor	Tenant	Reading and exporting the Audit Log, and nothing else. See Security.

Custom roles

When no built-in role fits, an administrator defines one on the Roles tab: a name, a description and the permissions it carries. A custom role behaves exactly like a built-in one: every screen and every API call checks permissions, not role names.

A custom role that can edit catalog records can be limited to specific catalogs when it is assigned.

Adding people

There are two ways to add someone, and the Users tab offers the one your deployment supports:

• Invite user, when the deployment can send email. The person receives a link, chooses their own name and password, and joins when they accept.
• Create user, when it cannot. You set a temporary password and share it with the person yourself; they must change it at their first sign-in. No email is sent.

Both need the Create users permission, and both ask what the person should get:

• Roles: pick a role and, for a project role, the project. A Reviewer can be limited to specific review steps of that project's workflow.
• Groups: under Add to groups, pick from the tenant's groups. The person gets every role those groups hold, now and as the groups change.

Give at least one role or one group. A person whose access comes entirely from groups needs no role of their own, which is the easiest setup to maintain: to change what a whole team can do, you change the group once.

You can hand out only what you could assign directly. A User Manager for one project cannot invite someone as a Reviewer in another project, and cannot add them to a group that holds roles in another project; such groups are not offered. Only someone who may assign any role can give Admin.

Pending invitations

An invitation is valid for 7 days. Until it is accepted it appears on the Users tab as Pending invite, with the number of roles and groups it carries; filter on Pending invitations to see only these. From its row you can:

• Resend invitation email: sends the same link again and restarts the 7 days. Useful when the first email never arrived.
• Cancel invitation: the link stops working.

When the person accepts, they get the invitation's roles and join its groups. A group deleted in the meantime is skipped; everything else still applies.

Someone who already has an account

People keep one account across tenants. If you invite an email address that already has an account (from another tenant), the person is added to your tenant, its roles and its groups at once, with no acceptance step, and is told by email. They keep their own password.

Create user refuses an address that already has an account: invite that person instead.

Inviting someone who is already a member of your tenant changes nothing. To give a current member more access, assign a role or add them to a group, as described below.

Changing someone's access

Open a person from the Users tab to see their details, with two tabs:

• Roles: the roles assigned to them directly. With the Assign operational roles or Assign any role permission you can assign and revoke roles here. Roles they receive through a group are not listed here; they are changed on the group, and the Effective permissions tab shows them with the group they come from.
• Member of: the groups they belong to. With the Create users or Remove users permission you can add them to a group or take them out.

The row menu also offers Rename (with Edit user profiles), Sessions (for tenant administrators; it opens the Security page's Sessions tab on that person) and Remove from tenant.

Remove from tenant (with Remove users) revokes all of the person's roles and group memberships in this tenant and ends their access to it. Their account stays, along with any other tenants it belongs to. Any personal API keys they created stop working; the confirmation says how many there are.

Groups

A group bundles people so that they receive roles together. Instead of assigning Reviewer at the same steps of the same three projects to every new reviewer, assign those roles once to an "Invoice Reviewers" group and add people to it.

On the Groups tab, anyone with View users can see the groups; creating, renaming and deleting them, and changing their members, needs Create users or Remove users.

• Create group: a name (unique in the tenant), an optional description and, if you like, the first members and roles. Roles are picked as on the group's Roles tab: the whole tenant or chosen projects, and the review steps or catalogs a role uses. If a role cannot be assigned, the group is still created and a message names the role.
• A group's detail has a Members tab (add and remove people) and a Roles tab (assign and revoke the group's roles, with the same role permissions as for a person).
• Delete group revokes every role the group holds, so its members lose the access that came from it. The confirmation shows how many roles and members are affected.

Rules worth knowing:

• Admin can be given to a group, for the whole tenant. That is how single sign-on makes people administrators: a group in your identity provider is mapped to a DocAI Fabric group that holds Admin (see Single Sign-On). Only an administrator can give a group Admin, and the tenant's administrators get an email when a group receives it and when someone joins such a group.
• To add or remove members of a group that holds a role for the whole tenant (Admin, User Manager or Security Auditor across all projects, or such a custom role), you need permission to assign or revoke that role yourself. The same applies to mapping a single sign-on group to it.
• The tenant always keeps at least one administrator who holds Admin directly, not through a group: that account is the way back in if the group, or the identity provider behind it, stops working. Removing, deactivating or taking Admin from the last such person is refused until someone else is made Admin directly. Make sure at least one of them signs in with a password, not through single sign-on, so they can still get in when the identity provider cannot.
• Groups cannot contain other groups.
• A group belongs to one tenant, and its members must be members of that tenant. Removing someone from the tenant takes them out of its groups.
• When a person has the same role both directly and through a group, with different review steps or catalogs, they get the broader of the two.
• If you manage users only in some projects, you can change a group only while all of its roles are inside those projects. This stops a group from becoming a way to hand out access to a project you do not manage.

Effective permissions

The Effective permissions tab answers the reverse question: not "what can this person do?" but "who can do this?". Filter by role, project, review step or catalog, and it lists every person who has that access, whether through their own role assignment or through a group, and which group it came from. With no filter it lists every assignment in the tenant.

Use it before an audit, when someone leaves a team, or to check that a new review step is covered.

Audit trail

Invitations, acceptances, created and removed users, role assignments and revocations, and group changes (created, renamed, deleted, members added or removed) are all recorded in the Audit Log, with who made the change.