User roles
Everyone who connects to Unblu, whether a visitor on your public website or someone within your organization, requires a user identity on the system. Unblu classifies user identities by role.
A user’s role defines many aspects of the permissions that user has in Unblu. Within a conversation, their participation type also play an important part in defining their permissions.
The possible user roles are:
ANONYMOUS USER
When an anonymous visitor launches the Unblu interface on a public website, an ephemeral identity will be automatically generated on the Unblu system for that user and assigned the ANONYMOUS_USER
role.
WEBUSER
When a customer is authenticated by a protected web application such as an e-banking portal, that authentication is also used by the Unblu server. The user is assigned the WEBUSER
role. Users with the WEBUSER
role can’t access the Agent Desk.
REGISTERED_USER
The REGISTERED_USER
role is used for agents using Unblu in your organization. This role grants access to the basic functions of the Agent Desk.
SUPERVISOR
The SUPERVISOR
role provides access to the team management functions of the Account Configuration interface as well as to the Agent Desk functions enabled by the REGISTERED_USER
role. In the Account Configuration interface, supervisors can:
-
Edit their teams and subteams.
-
Reorganize their teams and subteams but not create a new teams.
-
See all members of their own team and subteams.
-
Edit the team assignment of the users belonging to their teams or subteams, but not create new users.
-
Manage canned responses for their teams and subteams, and for the members of their teams and subteams.
ADMIN
The ADMIN
role grants access to the account-related functions of the Account Configuration interface. In addition, users with this role have access to the same Account Configuration interface and Agent Desk functions as users with the SUPERVISOR
role.
TECHNICAL_ADMIN
The TECHNICAL_ADMIN
role is intended for IT specialists who aren’t authorized to access personally identifiable information (PII) stored in Unblu. The role entails a number of limitations compared to the ADMIN
role:
-
Users with the
TECHNICAL_ADMIN
role have no access to the Agent Desk. -
In the Account Configuration interface, they can only access account-related functions.
-
Users with this role can’t configure webhooks, bots or external messengers. If they could, they would have an indirect way to access the contents of conversations.
-
The
TECHNICAL_ADMIN
user role has limited user management capabilities. Specifically, users with the role:-
Can modify the settings of users and teams
-
Can create, modify, or delete canned responses of a user or team
-
Can’t create, modify, or delete users, including themselves
-
Can’t create, modify, or delete teams
-
The TECHNICAL_ADMIN role isn’t available on Unblu Cloud deployments. |
SUPER_ADMIN
In addition to the permissions granted with the ADMIN
role, the SUPER_ADMIN
role grants access to the Global Server Configuration interface, enabling users to create and manage accounts on the Unblu server.
When not impersonated into another account, users with the SUPER_ADMIN
role can:
-
create, modify, or delete any type of user and team
-
create, modify, or delete canned responses for users or teams
When impersonated into another account, users with the SUPER_ADMIN
role have the same privileges as if they were in their own account. This may raise concerns about unwarranted access to PII. The configuration property com.unblu.storage.management.limitedImpersonatedSuperAdminUserManagementEnabled addresses these concerns by limiting what SUPER_ADMIN
users can do when managing users and teams in another account. When the configuration property is set to true
, a SUPER_ADMIN
who is impersonated into another account:
-
Can only create
TECHNICAL_ADMIN
users in the account -
Can’t create, modify, or delete teams in the account
The default value of the configuration property is false
.
The SUPER_ADMIN role isn’t available on Unblu Cloud deployments. |
Role-based feature access
As the role descriptions above suggest, Unblu’s roles are hierarchical in nature: permissions granted to a role further down the hierarchy are inherited by roles further up in the hierarchy. For example, since administrators are able to create teams, superadministrators can, too.
By and large, permission inheritance makes configuration management easier. It can, however, also lead to roles being granted access to features that you don’t want them to have. For this reason, access to some features can be granted to roles individually.
The picture above shows the setting that specifies which roles may delete conversations. As you can see, superadministrators may not do so even though administrators may.
The features that you can grant access to on a per-role basis all have configuration properties whose key begins com.unblu.permission.roleAllowed
. Access to the feature to delete conversations, for example, is determined by the configuration property com.unblu.permission.roleAllowed.deleteConversations.
It’s also possible to assign individual users and teams different permissions conversations and to revoke access to certain features. For more information, refer to User-based conversation permissions.
Superadministrators can change the settings that define role-based feature access. In principle, they can therefore grant themselves access to any feature. |
See also
-
For information on permissions in conversations based on the participation type, refer to Conversation participants and
-
For information on user-based conversation permissions, refer to User-based conversation permissions.