Custom roles
We revisited core functionality in our platform to make roles fully configurable in a user-friendly way while the platform takes care of the complex permission handling. The result: fully flexible permission to your dashboards, subjects, event triggers and properties!
The driver behind this feature: Multi-tenancy
A more fine-grained approach to user permissions was one of our top customer wishes. Previously, you had a choice between three default roles which was not enough for customers who would like to use our platform in a multi-tenant way. In these scenarios it is desired to have more fine-grained control over which subjects (e.g. assets, sensors and devices), dashboards, triggers, events, etc. a user can view, edit or manage. We now support custom roles, so you can define permissions and make sure all members’ permissions are tailored to your needs.
This blog explains custom roles with some examples to provide you a good view on the possibilities. A detailed explanation on this functionality can be found in the custom roles docs.
Custom roles examples
Configuring the permissions of a custom role is convenient and best illustrated with some examples.
Example 1: View specific dashboards for all subjects and some triggers
Do you have a group of persons who are interested in specific dashboards to get a high-level overview? And they want to have the opportunity to check the condition of a subject? This group can be managers, directors, customers or colleagues that need this steering information. The following role is an example configuration to realize this role.
Example 2: Manage triggers and subjects
This example is for the group of persons that need to act on events and adjust the triggers based on the events and subject information. This group can be maintenance engineers, field researchers, operators or other persons working closely with the devices, assets, sensors or other ’things’. The following role would suffice for such a group.
Example 3: View all subjects, view all properties and edit some properties
What if you have a customer that needs to edit some properties of their subjects, but also needs view all other properties? This approach is supported and here is an example.
Non-configurable permissions
Reading this blog you might think, what about the permission for events, project settings and some other resources which are not mentioned? We don’t like to make it more difficult than needed, so we try to handle all complexity under the hood and keep our platform user-friendly. With this in mind, we decided to derive the permission for some resources. After all, there is no reason to see events of subjects and triggers you have no permission to. So, you only see the events that are related to subjects and triggers you have permission to. Another example, project settings is typically a part of the platform that is solely managed by the Administrator. So, the default Administrator role is the only one who sees the project settings.
Our documentation provides more information about the non-configurable permissions.
Ready to try it out?
The custom roles functionality is available to use right now! Each customer and partner can start using this new feature in their project. Are you new to Blockbax and do you want to see it in action? You can reach out to us and will get back to you soon.
Enjoy using this cool new feature, and stay tuned for future feature spotlights to come 💚!
Cheers,
The Blockbax Team.
