Skip to main content

Roles and Permissions

Harmony uses role-based access control (RBAC) to decide what each member can see and do. Every member has exactly one role, and each role contains a set of permissions. Those permissions define both the action a member can take and how broadly that action applies across the workspace.

Accessing Roles​

Open Workspace Settings and select Roles. The Roles page shows every role in the workspace, how many permissions each role contains, and how many users are assigned to it.

Viewing roles requires the roles:read:all permission. Creating, editing, and deleting roles require roles:create:all, roles:update:all, and roles:delete:all respectively. By default, only the Admin role has these permissions.

How permissions work​

Permissions use a three-part format:

resource:action:scope

The first part is the resource, which is the thing the permission applies to. Common resources include conversations, users, projects, and billing.

The second part is the action, which describes what the member can do with that resource. Actions include operations such as read, create, update, delete, approve, and execute.

The third part is the scope, which controls how broadly the permission applies. A scope can be limited to the member's own resources, expanded to their team, or applied across the entire workspace.

For example, conversations:read:own lets a member view only conversations they own. conversations:read:team lets them view conversations that belong to members of their team. conversations:read:all lets them view every conversation in the workspace.

Scopes are hierarchical. The all scope includes team, and team includes own. If a role already has conversations:read:all, you do not need to also assign conversations:read:team or conversations:read:own.

Built-in roles​

Harmony creates three built-in system roles for every workspace: Admin, Team Manager, and User. These roles provide a starting permission model for common workspace structures.

The Admin role has full access to every standard feature except user impersonation. Admins have standard permissions at the all scope, including billing, organization settings, role management, integrations, and workspace data. This role is intended for workspace administrators, IT owners, and account owners who are responsible for managing the workspace.

The Team Manager role is designed for team-scoped management. Team Managers can read, create, update, and delete most resources that belong to members of their teams. They do not have access to billing, organization settings, role management, or integrations. This role is typically used for team leads, department heads, and sales managers.

The User role is designed for individual contributors. Users have own-scoped access and manage only their own resources. They do not have team-wide data access, billing access, organization settings access, role management, integrations, or project management permissions.

Harmony does not ship a separate "Owner" role. Workspace-wide control sits with members assigned the Admin role. Capabilities like deleting the workspace or managing billing are controlled by their respective permissions, such as organization:update:all and billing:*:all, rather than by a separate Owner persona.

Permission reference​

Different resources support different scopes. The available scopes reflect how each part of Harmony is meant to be managed.

Resources such as conversations, contacts, accounts, goals, automations, artifact, scorecards, and reports can use own, team, and all scopes. The available actions vary by resource, but they commonly include read, create, update, and delete. Scorecards also support approve, while reports support actions such as read, activate, and unhide.

Resources such as users, projects, api-keys, custom-fields, goal-definitions, and insights generally use team and all scopes. The users resource also supports own for self-management, while users:impersonate:all is only available at the all scope.

Resources such as skills and teams use own and all scopes. Workspace-wide administrative resources, including feed, billing, organization, integrations, sources, roles, permissions, and pipeline-rerun, use the all scope only.

Custom roles​

Workspace admins can create custom roles with precisely configured permissions. Custom role creation is not restricted to a specific subscription tier. Any admin or member with roles:create:all can create a new role.

To create a custom role, go to Settings -> Roles and click New Role or Add Role. Give the role a clear name and, if useful, add a description that explains who the role is for. Then choose the resources, actions, and scopes the role should include before saving it.

The new role becomes available immediately when inviting members or changing an existing member's role.

Custom roles are useful when the built-in roles are too broad or too narrow. For example, a QA Analyst role might need read access to conversations and insights without permission to edit or delete anything. An Integration Bot role might need permission to read and create conversations or contacts for an automated system. A Viewer role might provide read-only access to team resources without create, update, or delete permissions.

Editing or deleting a role​

To edit a role, go to Settings -> Roles, find the role, and click Edit. You can update the role name, description, or permissions. Changes take effect immediately for every user assigned to that role.

To delete a role, find it on the Roles page, click Delete, and confirm the action. Deleting a role removes it from the workspace and prevents it from being assigned in the future.

Deleting built-in roles, including Admin, Team Manager, and User, is strongly discouraged and may affect workspace functionality. The Admin role displays an additional warning when you attempt to delete it.

Assigning roles​

Roles are assigned when you invite a new user, and they can also be changed later from user settings. To update an existing member, go to Settings -> Users, find the member, open their role control or edit menu, select the new role, and confirm the change.

Because each member has exactly one role, changing a member's role replaces their previous permission set. The new permissions apply immediately.

How sharing interacts with permissions​

Sharing a conversation through the Share menu does not override role permissions. The recipient still needs a role that allows them to read the conversation.

For example, if a recipient's role only has conversations:read:own, they will not be able to open a conversation that someone else shared with them. Their read scope must be at least team, and they must belong to the relevant team, or it must be all. This is the most common cause of "I clicked the link but it did not work" reports.

FAQ​

Can a User delete a colleague's conversation?

No. The User role has conversations:delete:own, which is limited to conversations the user created.

Can a Team Manager see conversations from a team they are not on?

No. Team Manager access is limited by the team scope, which only includes teams the manager belongs to.

What is the impersonate action?

users:impersonate:all lets the assigned role view the workspace as another user. It is not included in any built-in role and must be explicitly added to a custom role if needed.

Why can't a user open a conversation someone shared with them?

Their role's read scope is most likely own. Update the role's scope to team or all, or assign them a role that already has the required scope.

For member and team management, see Teams and Users. For more about shared conversations, see Sharing meetings.