Contact usRequest a demo

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

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.

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.

Example of a role-based feature setting in the global configuration interface
Figure 1. Role-based feature setting that grants admins, but not superadmins, permission to delete conversations

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