The Problem

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

Constraints and Collaboration

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.

Phase 1: Discovery

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.

Phase 2: Defining Success & Goals

Our security initiative would be considered successful if the admin could accomplish the following tasks:

  • Creating a security group
  • Removing and adding users to a Security Group
  • Giving security groups Create, Read, Update, & Delete access to Record Types

Phase 3: Develop

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 & Groups
  • Record Template Access
  • Workflow Access

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.

Workflow Access
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.

Phase 4: Deliver

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.

Additional Improvements

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.

Security Rules
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.


I designed the UX for our security system from scratch.

Product Designer, Front-End Developer
Time Frame
3 months

My Work

View other projects