Customers needed a powerful way to limit their users' access to create, read, update, and delete Record Templates & Records in Winmore. There was no formal security system before the redesign - every organization had an open security model.
Security became an initiative because:
1) Company vision -- it was a basic feature leadership wanted to have in our application
2) Sales would have a stronger pitch with this feature
3) Specific requirements were part of customer commits
I was the lead designer working alongside a UX researcher, PM, and 5 engineers. We kicked the project off with our usual JAD (Joint Application Design), a meeting consisting of engineering, design, and a PM to set expectations and timelines. We touched base consistently throughout the entire process.
We collaborated with the Customer Success team and PM to talk to our Customers to determine the level of security they were looking for. the main goal for customers was that they wanted to restrict users from seeing specific Record Types and Workflows. They wanted to finesse the access to specify if a user had Create, Read, Update, and Delete access. We also collaborated closely with engineering, as this was a highly technical endeavor and the engineers would be spearheading the architecture of how security would work.
Our security initiative would be considered successful if the admin could accomplish the following tasks:
Our team whiteboarded many ideas. One of the hardest parts of the process was that the engineers would keep rearchitecturing how security would work, and we would have to recreate wireframes to adapt to the new architecture. The main users who would be using our product are our Customers' admins and our company's solution architects.
There were many different areas of the app that we had to implement security for, including:
Users and Groups
In the Studio (admin) page, we created a section called 'User Management and Security'. Upon drilling down into it, the admin can create Security Groups. The admin can then give groups different permissions.
After selecting a group, the admin can add users to the group. We explored many different ways of adding users, and did a lot of internal tests with Solution Architects. They particularly liked the pattern of being able to add and remove users on the right column; that way, they could manage access while referencing who was in a group.
Record Template (Record Type) Access
Upon selecting a group, the admin can add or remove Record Types and fine-tune Create, Read, Update, and Delete access.
2 years later, we did a re-design of Security to fit our rebrand, We implemented visual and interaction improvements. The visual design is much cleaner, and the admin can easily navigate between groups.
We also implemented the capability to manage a group's ability to Start a Workflow. At this point, 'Start' was the only option; however, we knew in the future it would scale.
2 years later, we redesigned the page to make it more visually appealing and easier to use.
We went through a period of internal beta testing and QA to fix bugs. Our Solution Architects were incredibly excited and loved how intuitive the product was to use. They appreciated being involved in the Design process. All of the goals we had defined were met, making the security project a success. We got feedback from Customers, and they were really excited with the functionality. General users appreciated it as well, as they no longer had to see Record Types that were irrelevant to their work.
As touched upon earlier, 2 years after the release we added more functionality to Security and redid the visual design and some interaction elements.
We added functionality for Admins to be able to edit Security Access via the Record Template Editor. In a Record Template editor, users can manage Security pertaining to that particular Record Template.
Upon clicking Security as shown above, the admin is brought to this overlay.
After selecting a Workflow, the admin can then manage Read and Start access.
During our redesign of security, we added the ability for Record Templates to have Security Rules. Some organizations have extremely specific security needs, and Rules were our way of meeting those. Dynamic conditions and field-specific access can be applied to a rule. For instance, security can be fine-tuned so that only the West Coast Sales group can Read, Create, and Update Opportunities located in the West Coast, and only view the ARR and Location fields.