Groups & roles
Access in LEMA Chat rests on two ideas: groups decide who and what knowledge belong together, and roles decide what a person can do. Together with the anti-escalation rule, they make access safe by construction.
Groups & clearance
- A group is the single unit of both membership and clearance.
- Every user has an implicit personal group, and everyone is in the workspace's All group.
- Brains and integrations are granted to groups, at levels Read, Write or Admin.
- A Brain or integration is usable in a chat only when every group present in the chat holds at least Read on it. This is the clearance intersection. It is narrowed further to what the person asking can read themselves.
The practical upshot: you grant access to groups, and the platform works out what is usable in any given room. Adding a less-cleared group to a chat narrows what is available there. Access fails closed.
📸 Screenshot: granting a group read/write on a Brain.
Managing groups
Groups are managed from the Groups section of the left sidebar. Its manage page has + New group and, for each group, its members. Creating a group needs the Owner or Admin role.
When you add a member to a group you can tick Facilitator to make them a Facilitator of that group. That is how the Facilitator role is given.
Roles
A person has one workspace role, set on the Users page:
| Role | Can do |
|---|---|
| Member | Take part: chats, assets, Brains they are cleared for |
| Admin | Everything a Member can, plus manage members, groups, agents, Brains, connections, integrations, plugins, applications, templates, courses, communities and tickets, run sessions, and see costs |
| Owner | Everything an Admin can, plus change the workspace's own settings |
Two more roles are added on top of Member:
| Role | Adds | How it is given |
|---|---|---|
| Facilitator | Running live sessions, widgets, the shared library, courses, communities and applications | The Facilitator tick on a group |
| Curator | Curating content: the shared library, templates, widgets and chat folders | By your platform operator |
A person's permissions are the union of the roles they hold.
Founder is not a role with permissions. Facilitators and above always read and write the workspace's company Brain from their role, with no group membership needed; Founders write it while the workspace allows it. See Founders and positions.
Any agent in the workspace can list exactly which permissions a role holds: the Handbook it reads from has a roles and permissions reference built from the product itself. Ask one, for example "what can a Facilitator do that a Member can't?".
Custom roles
Roles are data, not fixed code: a role is a named set of permissions. Creating custom roles and assigning them is done by your platform operator. A workspace admin's console has no Roles page.
The anti-escalation rule
Nobody can give more than they have.
- A role can never grant a permission its creator does not hold. The server checks this whenever a role is created, edited or assigned.
- The role rules on the Users page follow the same idea: only an Owner makes an Owner.
- An API key never exceeds its owner.
- An agent acts within the clearance of the room it is in and the person it is working for.
How it all composes
- Groups give clearance: what knowledge is allowed in a room.
- Roles give capabilities: what a person can do.
- Anti-escalation means nobody can mint power they don't have.