How the Backend Influences the Frontend in Technology System Implementation

Posted on: February 5, 2016

In our last article we reviewed the key steps to consider when implementing a workflow based technology system – establishing that a system can only be as good as the planning, configuration, and data entered into it – and an important part of this data is clearly understanding and defining the “role/s” of each potential user of the system. Accurately completing this task enables the technology system to automatically control the level of information and access privilege each user has based on their roles, pre-defined workflows, and peer groups. Managing user access in this manner is a form of security/privilege management methodology known as Roles Based Access Control (RBAC).

RBAC is a policy neutral access control mechanism which is based around the pre-defined user roles and privileges discussed in the “Key Steps to Consider When Implementing a Workflow Based Technology System” article referenced above.

Key Steps to Consider When Implementing a Workflow Based Technology System:

Roles are created for each job function and/or user type in an organization and then permissions are assigned to each role. A user cannot be setup on the system without being assigned a role as a mandatory first step and since users are no longer assigned permissions directly on an “as needed” basis but inherit them based on the role assigned it greatly reduces the potential of users receiving incorrect access rights and/or privileges. As a result, setting up users on a RBAC system is simply a matter of choosing the appropriate role for the user’s account type from a pre-populated list resulting in less potential for error and standardization of all user profiles on the system.

Defining the roles is a very straightforward task that takes place during the corporate workflow evaluation process and there are three primary rules that must be considered when preparing to implement RBAC:

1. Role assignment: A user can exercise a permission only if the user has selected or been assigned a role.
2. Role authorization: A user’s active role must be authorized for the user. With rule 1 above, this rule ensures that users can take on only roles for which they are authorized.
3. Permission authorization: A user can exercise a permission only if the permission is authorized for the user’s active role. With rules 1 and 2, this rule ensures that users can exercise only permissions for which they are authorized.

 

The technology system’s corresponding interface can be made highly intuitive so that, after all roles and associated permissions and workflow engine modules are implemented in the centralized database, the role-based privileges can be entered and updated quickly across multiple offices, peer groups, and user locations all by a single support user or team. There is no longer a requirement to have specific domain expertise with respect to each user’s role and access privileges as long as the new user’s role is provided upfront with the request. This translates into a single company-wide quality control process for managing all users while ensuring the desired level of security and access is always accurate.

In addition to support, administrative efficiency, and quality gains RBAC also has the added benefit of providing the end user with an enhanced experience as well. In traditional technology systems that don’t utilize pre-defined roles they often rely on the end user to make choices in real-time with respect to the actions that they wish to take on the system. For example, in a case where a user wants to perform a simple task such as send/receive messages pertaining to a claim file the user will likely have to perform multiple steps or “clicks” to set the framework for the action that they wish to complete.

Commonly these include:

• Choosing their role on the file and searching for the corresponding file to open
• If multiple files are open choosing the line of business the action pertains to
• Selecting the appropriate repository of forms based on the file type the user is in
• Choosing who the user is the action should be directed to
• Determining what their level of access to the action and/or file should be
• If a message is received determining which file and category it should be appended to
• If it is a reminder or a future action they must set a manual abeyance

Conversely, with a RBAC system in place, it eliminates most if not all of these “preparatory” steps because the system and all the users are already pre-defined based on their roles and their corresponding workflow engine modules. All of the information will automatically flow to and from the appropriate files and corresponding participants with the appropriate privileges and greatly minimize administrative burden as well as the potential for user error. By eliminating most of the repetitive, redundant, and mindless administrative tasks required under previous “siloed” technology systems RBAC enabled organizations are also better positioned to meet their own statutory and regulatory requirements for privacy and confidentiality which is particularly crucial for companies dealing with personal/confidential information. In addition, company management are now able to monitor at a global level how data is being accessed, by whom, and for what purposes resulting in enhanced regulatory compliance and information due to the standardized processes.

The other advantage of RBAC is that it can be extended to become an attribute-based access control or ABAC which considers additional attributes in addition to the primary roles and groups based rules. This results in even greater system flexibility because ABAC provides the ability to utilize RBAC policies that combine attributes together and can even include dynamic elements which determine a user’s status based on their involvement in a file.

In summary, when choosing and setting up a new technology system it is important to not only focus on system functionality but also on the system’s administrative back-end infrastructure. As supported by this RBAC example, the robustness of a system’s backend user based configuration ability is a strong predictor of a system’s ability to deliver on the ultimate goals of enhanced quality, efficiency, end-user experience, and analytical reporting capabilities.