REUSABLE LISTS | MICROSOFT PURVIEW
Designing to increase efficiency and cut down repetitive manual work
Data loss prevention admins were spending a lot of time managing lists across their policies. The process was all manual and repetitive. A small error could pose a potential threat to data security. In this case study I talk about how I designed an experience solving for repetition of a task.
Private Preview · May 2026
160+
billed tenants
390
Lists created in 1 month of Private Preview
*Sourced from the Private Preview phase. Due to NDA requirements, the impact metrics shared here are approximations.
01/ CONTEXT
Before we dive in
Don’t want to read this? Skip to 02 /problemWhat’s Microsoft Purview?
Microsoft Purview is Microsoft's compliance suite for enterprises, a set of tools that help organisations protect sensitive data and meet regulations like HIPAA, GDPR, and others.
What’s Data Loss Prevention?
Data Loss Prevention (DLP) enables DLP admins to create policies that stop sensitive information from being shared with unauthorised people
DLP Policy check
Authorised
Unauthorised
Allowed to share
Sharing blocked
This content contains sensitive information
Learn more.
02/ THE PROBLEM
Managing the lists used in policies is a manual repetitive task
- A Data Loss Prevention policy is made of rules
- A policy may have 100s of rules
- Some of these rules have a long list associated with them
An organisation wants to block 1,000 domains in a DLP policy.
Created a rule and had to manually enter all 1,000 domains.
The organisation wants to block the same 1,000 domains in another DLP policy
Created a rule and had to manually enter all 1,000 domains again.
The organisation needed to add just 10 new domains to the list
Opened every single rule and updated each one manually.
Customers already paying for Purview seats and subscriptions were hitting this wall. Collectively, over $9.75M of that revenue sat with organisations stuck in it.
The Challenge
Adding and managing lists in a DLP policy
- repetitive,
- manual and
- time-consuming
How might we help compliance admins manage their lists with ease?
03/ THE PROCESS
Design and strategy decisions for creating new experiences, migrating old ones.
01
The architecture: Is this a shared problem?
HYPOTHESIS
My first hypothesis was list creation might be a global Purview pain-point.
Since most Purview solutions involve creating a policy.
I researched and found a list creation structure within Insider Risk Management (IRM).
HYPOTHESIS RULED OUT
Role Based Access Control
- Brainstorming with my PM brought up this structural constraint.
- Purview and solution level RBAC are separate systems.
- A global feature would force solution admins to hold a second role just to manage their lists, adding friction.
Weak cross-team motivation
- Discussion with IRM designer and PM revealed that they had not encountered any user pain-point related to list management yet.
- Moving Insider Risk Management list creation to a shared backend without clear business justification would be a hard sell.
Decision made that Reusable Lists would live inside DLP settings.
A note:
During AB testing, a compliance admin, unprompted, described wanting to manage lists globally:
Close to the hypothesis I’d already set aside. It didn’t change the decision, but it signalled the Purview-wide version of asset management could possibly be something to explore in the future.
“In your settings set your global allow global exclusions, global domains, global IP address blocks. You could have each of those lists and… define which list you wanted to use.”
— EY
02
One List, Every Workload
THE FRICTION
- Endpoint DLP has its own dedicated settings page where list creation already existed, scoped only to Endpoint policies.
- Endpoint DLP also supported more list types than Reusable Lists was scoped to cover.
THE TWO OPTIONS AT HAND
Move everything
Heavy backend rework not fully in the control of the feature team, and a real risk of a support ticket spike if admins couldn’t find lists that had moved without warning.
Move nothing
Endpoint stayed fragmented from the new system, with admins maintaining two lists for the same item in two places, undermining the point of the redesign.
I made the case to my PM that one list per item, across every workload, was worth the added collaboration and trade-offs. The reasoning held immediately, neither of us wanted to ship a UX split this obvious.
03
Solving the Migration
THE TRADEOFF
- Endpoint’s team and our team didn’t have bandwidth to migrate every list type right away.
- Some Endpoint specific lists would remain in place temporarily, not ideal, but better than two systems of record for the same list.
THE PLAN
2-month overlap where the list creation experience stays in 2 locations
Inform the user about the migration over the two-month period.
THE EXPERIENCE
3 methods used:
- Banner with list of moving settings.
- Badges denoting which setting is moving and which has moved.
- Adding migration information to the FRE
- Banner with list of moving settings.
- Badges denoting which setting is moving and which has moved.
- Adding migration information to the FRE
04
Designing for visibility
CONTEXT
DLP policy creation is a very mature workflow and DLP admins are well versed in it.
HYPOTHESIS
Minute changes in policy creation with additions such as the case with this feature could be missed.
A/B TESTING
USER TESTING INSIGHTS ON OPTION A
“This one is way more intuitive… One statement and one function that I can click on. Having two just confused me from the beginning.”
– EY
“I prefer this layout... it’s a little cleaner. The create list and add list are not separate.” THIP
“I think this is better because… they might create one without realising it’s already there.”
– Vodafone
CONSTRAINTS
Reusable lists could not be created while in the DLP policy flow.
As anticipated, feedback from users was to create reusable lists in the policy creation flow.
While we could not pick this now as a problem to solve, over the release of the feature we would monitor for more feedback around this.
“My preference would be to stay within the policy... and have a flyout... That way I’m not leaving this page.”
— THIP, on being redirected to the DLP settings experience to create a list.
05
Designing inside the gap
CONTEXT
The Purview portal had gone through a design system upgrade about a year prior, but the settings page still ran the old UI.
OPPORTUNITY
Get the new Fluent-security Extension design language into the settings page.
I got buy-in from the feature team.
Drag to see before and after
HEURISTIC EVALUATION
Audit and heuristic evaluation of the list creation experiences in the Endpoint DLP settings.
04/ ADDING IT ALL UP
05/ IMPACT
Users bringing over $9.75M of revenue were facing this pain-point
Feature in Private Preview since May 2026
PRIVATE PREVIEW NUMBERS
- 160+ billed tenants
- 390 lists created in 1 month
"We have an immediate need for something like this... When we originally were looking at our migration from Symantec to Microsoft Purview… that was one of the red flags we had called out right away – a lot of the policy work in Symantec was leveraging reusable lists… and there was no easy way to replicate that across the Microsoft space."
- The Hartford
"The feature in general… is going to be beneficial for sure. We needed this kind of thing."
- Accenture
06/ TAKEAWAYS
Thinking in systems
With a feature like this, rework could have been avoided if teams had the Endpoint list creation experience as a DLP feature. So as a designer, it was a great learning at zooming out and looking at if the requirement has a wider scope.
Tradeoffs in stride
The complexity of enterprise software isn’t always in the UI; it’s in the systems behind it. Understanding how policies, rules, and dependencies work helped me understand the reasons why a suggested solution may not work or be costly to implement.