What I learnt about designing Permissions framework for an Enterprise software
Anyone, who has ever tried to procure enterprise software for their organization or sell their software to enterprises, can comment about the importance of stable, granular and robust permissions models in enterprise software. It’s a “must have” platform feature that lot of companies do not pay enough attention until customer (existing and new) start demanding for it.
In fact, software permissions feature can be traced back to some first generation software ever written and a amount of decent technical literature is available on this topic. However, as a PM trying to learn about the best-practices in designing one, I wasn’t satisfied with what’s out there. Having talked to other PMs who implemented permissions framework and studying other “best-known” enterprise software (mostly cloud based softwares as I manage a SaaS product), I wanted to pen down and share my learnings.
Enterprise applications such as Salesforce, MS Dynamics or Oracle Siebel, have a wide array of features and try to address the needs of various market segment. Our product, which tried to address the needs of organization’s post-sales process needs, also showcased a wide variety of capabilities to address the needs of customer of various sizes and maturity. Thinking of one permissions models to fit the needs of all product feature would restricted our product’s capability or not address our customers’ needs.
To drive consensus across the various departments of the organizations and promote crisp understanding of the proposed framework, we categorized permissions into following types:
Record (data) Level Permissions
ERPs or CRMs are a treasure trove of data.Within few years, as the product adoption increases in the organization, the records stored in these systems(usually stored in forms Objects, data stores and entities) reaches to few millions. Due to the scale of operations and processes defined in these organization, enterprises need record level permissions i.e who can see what information in the application. However, as we are dealing with enormous volume of data and are created/modified very often, hence, UX for defining, managing and validating data access needed to account for this characteristic.
Asset Level Permissions
Our product also allowed customer ways to collect or share data via robust reporting and surveying infrastructure. We categorize these as Assets in the system. Assets can be system generated or user created; usually number of assets per customer ranging in ‘thousands’ and are created/modified often. To model permissions and sharing UX for this category, we took learnings from well know asset management solutions like Dropbox and GDrive.
Enterprise customer ability to control object or attribute level permissions. This would allow organizations to hide part of record’s information to user based on the sensitivity of that information. For instance, CSMs have access to the account information but do not have the access to ACV or ARR information in the account record. Similarly, only finance team have access to transaction and payment object. Objects and attributes can be both system generated or user created, but are usually created/modified less often (mostly by admins)
This is the most common and widely-used permissions types in products to control access. This permissions will help to design which product feature that user have access to and what action or operation an user can do w.r.t those features.
System level Permissions
These are special type of permissions that would help provide ‘select’ users access to specific tools and application configurations that determine how the the application behaves. In terms of modification, these are least modified and only a few users of the product have access to them.
Following 2x2 would summarize the categorization:
Our Approach to Solution Design
Firstly, to design for data access permissioning, we looked into rule-based-access-control framework. This framework helps admins to define a criteria using which system can resolve if the accessing user has permission to access the record. Additionally, we also defined system behavior to handle related objects, inheritance and conflict resolution(between policies).
Second, we designed UX of sharing assets to mimic what users are familiar while using other consumer apps for their day-to-day activities. For eg, Google drive files to share documents or pictures with friends and family. We introduced notion of public and private assets that users can leverage while sharing assets with organization’s users.
Third, to make manageability of feature and object metadata permissions simple and intuitive, we explored permissions bundling. Bundling was a system construct we introduced that allowed admins to club together set of permissions into a package (inspiration taken from OOP’s encapsulation property learnt while writing software). These permission bundles can be assigned to user or groups of users, which would then decide with feature and operations the user has access to in the system. A bundle can be assigned to multiple users (or user groups) and user can be assigned to many permission bundles. This ensure that admins had flexibility to model the product’s feature permissions based on the business processes.
Lastly, System permissions can be set in application configuration sections which only few super (or system) admins can access. These would define how the application would behave.
Thank you for reading. Please leave comments and feedback.