Over Permissioned and Under Enabled

By Kizen Ken

  • Linkedin logo
  • Twitter Logo
  • Facebook logo

When it comes to empowering users in Customer Relationship Management tools, an administrator has the ability to allocate what type of data they would like a user to access. Depending on the platform, the administrator may allow visibility, editability, or creation/deletion of record types at all different levels of data. Various CRM tools have differentiating capabilities of individual field access vs. record type. Let’s talk about the typical issues that can potentially occur. 

Too many permissions

Ironically, a key example of a low use rate and a data integrity problem stems from users having too many permissions. Unfortunately, powerful permission engines may not be available to administrators when setting up user access – this can become a complicated issue. Other times, issues can be caused by simple workflow misunderstandings. For example, imagine an inexperienced chef looking to make a specific meal; instead of having a recipe, they only have the ingredients. All of the resources are available, but there is no dictation or direction that would enable the individual to prepare the meal correctly, or in a timely manner.

Removing permissions can be a good thing. They say “less is more,” and for some users, that can actually be enablement for various reasons. If an administrator can limit excessive data points and inherently direct that user to what’s important to them, time is saved and can help with the next steps. Data integrity can remain sound if an administrator can prohibit duplicates or entries of false data to fields unrelated to certain users. If an organization wants to keep all financials and intellectual property data in their CRM but doesn’t want all users to access this, permissions can save data leakage. All of this can be done with the Kizen platform. 

Take a look below at some screenshots of the permission engine in action.

Here is the basis of all field types granting access or limiting access:

In the screenshot above, we can see all the different actions and interactions a user can have with a particular record type, in this case, Contacts. 

Below, you will now see different field types that exist on the record (critical details) that we want to allow the user to have access to or not.

In both screenshots, we can see the user can either create/delete, view, or not see these actions/fields, developing the ability to create different user engagement at all levels. 

If we take this same example and look at the record from two different views, we can see what a live record object’s view looks like. 

Here’s a partial look at all of the custom objects available in this business as an administrator, including the ability to add a new object that doesn’t exist yet:

 

Permission types

Creating permission types for repeatable, easy onboarding from a technology standpoint is something to consider when creating user roles. Kizen has hundreds of limitless permissions that users can customize and with every release, new actions and permissions will remain available to administrators. Kizen has no required structure in place any organization must adhere to. 

In summary, the Teams, Roles, and Permissions function in the Kizen platform allows for any granular permission to be accessed, visualized, or made invisible to any different team member or user at any time.