Roles and permissions

In the current SquadOS model, a Role is a permission package assigned to a person. The old Department name still appears in compatibility links and data, but it no longer represents a current screen for building an org chart, grouping agents, or filling rooms.

Where to review Roles

Open Settings → Users → Roles. The tab appears for the owner and for people with Manage access control. The old /settings/departments address redirects to the current tab.

The catalog is read-only: it explains what each Role can and cannot do. Assignment happens when you invite a person or open their record under the Users tab.

Preset Roles

Role	Intended use	Important limits
Administrator	Broad organization administration and every assignable product capability	Does not replace the owner for billing, ownership transfer, or closing the organization
AI Agents	Create and configure agents, knowledge, tools, and automations	Does not grant customer support or control over other people’s access by itself
Support	Conversations, contacts, quick replies, email, and contributing to knowledge bases	Cannot create agents, connect channels, delete knowledge bases, or manage access
Collaborator	Hub, Rooms, and Meetings	Does not include support CRM or administrative settings
Custom	A person-specific capability selection	Cannot be combined with preset Roles or reused as a named group

The catalog’s exact permissions are the source of truth. Review the Roles tab before granting access because the product may expand or restrict a package as it evolves.

Combine Roles

A person can receive more than one preset Role. Effective access is the union of their permissions: adding another Role never removes access. When a selection already contains every permission from a smaller Role, the interface automatically marks that Role as included.

• Administrator already contains every other preset package.
• AI Agents and Support already include the Collaborator access floor.
• Custom is exclusive: selecting it defines a dedicated set instead of combining packages.
• The owner has full access outside this catalog. Use the separate ownership-transfer flow to change the owner.

Assign during invitation or from the user record

When inviting someone, enter their name and email, select at least one Role, and send the invitation. For an existing person, open Settings → Users, select their row, change the Roles, and save.

The bulk action applies one preset Role to the selected people; it does not create a combination and does not offer Custom. Edit each user record for those cases. If you change your own Role and lose access to the current screen, authorization reloads and SquadOS sends you to an allowed area.

Also see Users, Roles, and Teams for invitations, user states, plan seats, and ownership transfer.

Create Custom access

After selecting Custom, choose capabilities grouped under:

• Hub and rooms;
• Meetings;
• Support and CRM;
• Agents and knowledge;
• Operations;
• Settings and access.

The product adds dependencies automatically. For example, write or delete access generally requires the corresponding view access, and managing access control also includes viewing users. Access rooms remains mandatory and cannot be cleared in the checklist.

Review access control manually

Manage access control allows someone to invite, remove, and move people and to change Roles — including their own access. The current interface does not display the critical warning and acknowledgement prepared for this capability. Before saving or sending the invitation, review the selected capabilities a second time and grant this power only to trusted administrators.

Roles do not fill new rooms

Having Access rooms unlocks the area, but it does not make the person a participant in every room. Select people and agents explicitly when creating a room. Room categories organize navigation only; they do not grant or remove access.

Migrated rooms may retain old grants inherited from a department/Role. In those rooms, some people appear as participants Through role and are locked in the selector. Saving the room preserves those old grants.

Known limitation in migrated rooms

The current interface has no safe control for removing only an inherited grant. Participant details may tell you to adjust departments in room settings, but that field does not exist; it may also attribute access to the Administrator platform role even though the current contract requires room participation. Do not change the person’s Role solely to fix one room, because that changes all permissions and other inherited rooms. If selective removal is required, treat it as a product limitation and ask the technical owner to review it.

For the full participation flow, see Rooms and direct messages.

Quick diagnosis

• The Roles tab is missing: your account does not have Manage access control. Ask the owner or an authorized administrator.
• An area disappeared after the change: review the union of Roles on the user’s record; losing the route capability causes a redirect or access denial.
• Someone cannot enter a new room: confirm Access rooms and add the person explicitly to the room.
• An inherited participant cannot be removed: do not look for a Departments tab; this is the migrated-room limitation described above.