Overview
This fundamentals article introduces users to the user access controls that are available in Emersion. It explains the concepts and objects underpinning the permission module so service providers can secure access to the system in a way that best suits their requirements. We encourage you to read this article to get an understanding of the various components, and then compliment your new knowledge and watch the Permissions Basics video to see these concepts applied to a new staff member.
Permissions comprise the following building blocks that all work together to grant/limit access to modules, features, functions, pages and page sections.
- Staff Users
- Org Units
- Role Groups
- Module Permissions
- Powers
Staff Users
A staff user refers to a specific type of contact in Emersion's platform that provides access to Cumulus. Once a person has a staff user account, they can log into Cumulus and perform all the functions to which their staff user account has been granted.
Access is controlled by a username, realm and password. The username and realm can be concatenated to form a single string. The realm is frequently defined as the company's own domain name '@mycompany.com.au' so that usernames can adopt the staff member's email address they are familiar with. I.e. An example of the username + realm = joe.citizen@mycompany.com.au.
A staff user must belong to an org unit. This is a one-to-one relationship, meaning a staff user can only be a part of a single org unit.
Org Units
An Organisational Unit (Org Unit) can be thought of as a group of employees who are performing the same functions. Often this aligns with departments and job roles, but that is not always the case. The Org Unit is primarily used as a binding object. Specifically, it binds together:
- staff users and permission groups
- agent accounts and their commission plans/tiers
- agent accounts and their account group
If Emersion was used by all employees in your business, it would be quite likely there would be an org unit or two required to represent every department or job role in the organisation's structure.
By default, Emersion provides a number of org units typically found in companies. Using them is not essential. Service providers are welcome to create their own, or rename the ones provided to reflect their own business structure. If they are to be used, they will need to be configured. They are provided as empty container records for this purpose.
Roles
A role contains module permissions and powers in an enabled or disabled state that form a specific level of access for a person/role. A role can be linked to multiple org units. Any user belonging to an org unit containing a role will adopt the permissions as defined in the role.
- Some service providers use role groups to grant access to certain features and functions and then attach the roles to the org units who require it.
- Other service providers choose to have a role or two per department and define all the permissions those staff need in those role groups.
The flexibility of the structure means service providers have ultimate control over how many org units and roles they need. However, at the end of the day, each staff user must be part of an org unit with at least one role with module permissions and powers defined. Use the diagram above showing the relationships between these components as a guide.
If a staff user is linked to an org unit with no role group, or the role group has no permissions or powers enabled, the user can log into Cumulus, but they will receive permission errors when the Customer List screen tries to load.
If a permission or a power is enabled, and the user belongs to a company who has not subscribed to the module/feature/function that the access control governs, no access is granted. The permission module controls access to only the parts of Emersion's platform to which you are subscribed.
Module Permissions
Module permissions (or permissions) control access to modules and features. It controls menu items, tabs and some sub-tabs and some page sections where they belong to a specific module.
Module permissions are not hierarchical. There may be more than one module permission needed to enable a whole module.
Powers
Powers are a more granular form of access control than module permissions. Powers are hierarchical, unlike module permissions. The lowest power in the tree will give minimal access, whereas powers higher up in the hierarchy (i.e. the parent power) will grant additional powers. The higher you go to enable powers in the tree, the more power/access you have.
Powers do not enable and disable entire modules or features, but can determine what a user can do when they use it. For example, on the right are the powers related to the disputes feature. Disputes is a core module. There is no permission to enable/disable it directly, however disabling all of these powers will prevent users from performing the various dispute-related tasks.
The Base Power that sits at the very top of the powers hierarchy enables all the powers in the system.
Users cannot change their own powers. If you are part of the Org Unit called ABC123, you can only adjust powers in a role that is NOT IN the ABC123 org unit.
Powers for Disputes
Administrator (Full Powers)
One of the first things Emersion does when we on board a new service provider is set up the service provider account(s).
Each service provider account comes configured with the following:
- An Role group called Administrator (Full Powers) - Emersion enable module permissions and features that have been subscribed to as set out in the Emersion Services Agreement.
- An Org Unit called Administrator (Full Powers) - the Administrator (Full Powers) role group linked to this Org Unit.
As the name implies, these users are granted full access to all modules, features and functions that the company has subscribed to. If users require access to 'everything', add them to this org unit.
Account Groups
Account groups are not part of the permissions module and are not to grant or deny access to features and functionality. However, it is relevant to mention here because of the ways account groups can be used. Account groups can be used to grant or deny access to a collection of child accounts. In cases where a service provider wants to prevent a user to being able to access the entire customer base and provide access to only a subset of customers, account groups are used to achieve this objective.
For managing access to modules, features, functionality and read and write access, use the permissions module.
For managing access to customer accounts, use the account groups module.
Case Example
This section provides a basic case scenario that demonstrates the relationships between these objects in a practical way.
Requirement
You work at a Service Provider who has a subscription to the Payment Plans module. You decide that there will be two levels of access to the module:
- The customer service team members will be able to see the payment plans of a customer but not change them in any way.
- The Customer Experience Manager leads the customer service team. They have adequate authority, so requires the same level of access as their staff, plus access to edit a payment plan, change the payment schedule or cancel it.
Solution
First, each staff member in the team will need their own Cumulus staff user login.
Two role groups will also be needed.
- Payment plans - Read only
- Payment plans - Full Access
Both role groups require the Payment Plans module permission to be enabled. The module permission grants access to the Finance > Payment Plans page and the Customer > Payment Plans tab.
The role group for customer service staff will require the View Payment Plans power under the Finance parent power (highlighted in orange).
The role group for the team's manager will require the same power plus all of the powers under the Payment Plan parent power (highlighted in yellow).
| Payment Plans - Read Only | Payment Plans Full access |
|---|---|
|
|
After the role groups have been configured, each role group needs to be attached to each staff user via the org unit. As mentioned earlier, the org units grants the same level of access to staff who belong to it. Since the requirement of the case scenario is to have two distinct levels of access, two org units will be needed. In this case, we will keep the names aligned, but it is not a requirement to do so.
- Org Unit 1: Customer Service Team - Staff
- Org Unit 2: Customer Service Team - Manager
Then, the roles and org units are related as follows:
| Org Unit | Role Group |
|---|---|
Customer Service Team - Staff | Payment plans - Read only |
Customer Service Team - Manager | Payment plans - Read only Payment plans - Full Access |
The final step is to place each staff user into the appropriate org unit.
After this, the configuration of the permissions has been finished and will meet the requirement of the use case.