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. The possible roles are:
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
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 role is used for agents using Unblu in your organization. This role grants access to the basic functions of the Agent Desk.
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 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
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
Users with the
TECHNICAL_ADMINrole 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.
TECHNICAL_ADMINuser 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
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
SUPER_ADMIN who is impersonated into another account:
Can only create
TECHNICAL_ADMINusers in the account
Can’t create, modify, or delete teams in the account
The default value of the configuration property is
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.
Superadministrators can change the settings that define role-based feature access. In principle, they can therefore grant themselves access to any feature.