Critique our permission structure for SimpleDocs
How do we ensure simplicity and needed configurability?
As part of our product development at SimpleDocs, we have created a permissions model to structure user access to the platform and key actions (e.g. editing rights, etc). We are seeking feedback from you on whether this model makes sense and if there are any key use cases that we may have missed. This is pretty long and detailed, so thanks in advance for making the time.
Proposed Permissions Model
We have identified four permissions for workflow/request access (which symmetrically match repository permissions), three key role assignments for the requests, and two organizational-level permissions. These permissions are outlined below.
1. Workflow/Request Access Permissions
Request: This permission allows a user or group to create a request in a specific workflow. The creator of a specific request will always have the view and comment permission on their own requests.
View: This permission allows a user or group to view a specific request or an entire workflow's requests.
Comment: This permission allows a user or group to create internal comments on a workflow's request or in a specific request.
Edit: This permission allows a user or group to make edits to a request, edit the agreement, upload new document versions, send the document to the counterparty and so on.
2. Role assignments for a request
Business owner: This is the person who made the request. By default they will be able to view and comment on their own requests, and take actions like cancelling the request. In cases where a workflow designer has allowed it, they may be able to edit the request.
Approvers: These users or groups (in case of a group, a user from the group will be assigned) must approve the request before moving to signature.
Approvers will have comment access permissions. This default may be changed for the org, or for the specific workflow or request.
Signers: These users or groups (in case of a group, a user from the group will be assigned) must sign the agreement to full finalize the agreement.
Signers will have view access permissions. This default may be changed for the org, or for the specific workflow or request.
3. Default user groups with specific permissions
Designers: This group has permission to design workflows (with specific templates, tagging and conditionals, and specific roles and permissions) and publish them for others to use.
Admins: This group has permission to create groups, invite new users and add them to groups, as well as configure default settings for workflows or requests.
Org members / Everyone: This group may see who else is in the org, and which groups exist. They may only see the members of the groups they are members of. They may only see workflows/requests and repository documents where they have specific access permissions.
4. Repository document Access permissions
Upload: This permission allows a user or group to upload new documents to a folder.
View: This permission allows a user or group to view a specific document or the documents within a folder hierarchy.
Comment: This permission allows a user or group to comment on a specific document or those in a folder.
Edit: This permission allows a user or group to make edits to a document's metadata. They may also perform actions like cancellations or renewals.
Concrete example of how this works
The top part of the diagram shows people in groups (large circles) and as individuals (small circles). People are mapped via specific access permissions and assignments to workflows or specific requests.
See the diagram below showing user/groups, permissions, roles, and workflow requests.
In this example, someone in sales requests a specific NDA for an opportunity which has HR impacts. For instance, maybe the sale will require new hiring to support it.
The sales associate is able to create the request so because of the request permission granted to the sales group on the workflow.
Further, when a specific member of the sales group makes a request, they take on the role of the business owner for the specific request. Hence the dotted line from the create permission on the workflow to the business owner role.
The business owner may view and comment on the specific request, as indicated in the diagram.
As this request inherits the permissions from the Sales NDA workflow:
Everyone in the company may view the Sales NDA workflow.
Members of the legal group may edit the requests (which includes the ability to view and comment on them).
Finally, org admins my also edit the workflow requests.
In addition to these, however, the HR group is given comment permissions. For instance, the sales person may want HR to have a head’s up on the opportunity. (This is just an example of how granular permissions can be provided at the specific request level as needed.)
A note on confidentiality: We are aware that some of these requests should be private or confidential.
Workflows will be configurable so that business owners or editors may set a request as confidential.
In those cases, inherited permissions from workflow will be blocked so that only specific individuals with clear roles for the specific request (business owner, approver, signer) would have visibility.
Feedback Requested
We would appreciate your feedback on our proposed permissions model. Specifically, we would like to know:
Do these permissions make sense?
Are there any key use cases that we may have missed?
Is this model too complicated?
Are there any patterns from other CLMs that you love or hate?
Conclusion
Our goal is to create a permissions model that is clear and easy to manage. Your feedback will help us achieve this goal. Thank you for your time and input.
Overall, I think the permissions make sense that you've outlined. Being in software as well, while I certainly agree that simplicity and usability are important for your software, when it comes to permissions, I don't think that you can ever be too granular or complicated in your permissions. Customers always want the ability to customize and have more granular control over how the hand out permissions in your software instance. So it should be easy to set up and manage your permissions but the more options and the more granular you can get, the better in my opinion.
The one thing I might ask about is how repository access will work as it relates to your folder structure? It was important to us that permissions could match how we wanted to structure our folders as we wanted to do it a bit differently than the standard folder set up our CLM provider recommended (by contract type rather than by counterparty). Will you support different folder structures with your repository access permissions?
1. Do these permissions make sense?
Yes – these permissions make sense. One other factor to consider is the importance of data privacy as the laws continue to evolve in that area and how you can set features to allow for the correct privacy (especially if you are going to have global access).
2. Are there any key use cases that we may have missed?
Yes. One of the use cases is deletions. I worked at one company that this became a huge issue of people deleting files that others disagreed should be deleted and led to loss of vital files. Eventually a control was put in place that a certain person had to approve the deletion before the file could be deleted. You’ll need to determine how broad deletion approval is based on turnover in this current climate. Second use case is how you will handle editing in connection with versions. Is a person promoted or able to create a new version before editing? Redlining is an important concept for legal practices and it’s hard to keep version control with out the ability for versions.
3. Is this model too complicated?
It looks complicated in written form but not complicated in process. When you put together the actual sales pitch and manual, I’m sure you will have a more user friendly/read and/or presentation version of how it works. A great CLM tool must have the necessary permissions and controls to actually work in practice. It being too simple is why one company I worked at changed vendors because as a company grows and laws change (e.g. privacy laws), a more complicated system is necessary (read: legally required).
4. Are there any patterns from other CLMs that you love or hate?
I liked the approval on deletion and prompts for should a new version be created for editing purposes.