Simple Permissions, Powerful Consequences

Why This Problem, Why Now

This project didn't land on my desk as a neat brief. It emerged from converging signals that something was broken.

Support tickets about permissions had been climbing steadily. Merchants were reporting unauthorized refunds processed by staff who shouldn't have had access. Customer data was being viewed by employees outside their role. In enterprise sales conversations, prospects kept asking the same question: "Can we restrict what our staff can do?" The honest answer was "not really," and deals were stalling because of it.

The existing system was a liability. Under GDPR, the inability to restrict data access wasn't just inconvenient—it was a compliance risk that put merchants in legal jeopardy. Shopify Plus was growing fast, but the permissions model was still built for the small merchant with a handful of trusted employees. That mismatch was creating real problems.

When I joined the Ability team as Lead Designer, the mandate was clear: fix permissions before it became a blocker for enterprise growth. What we built had to satisfy three stakeholders at once—security teams demanding tighter controls, ops teams needing flexibility, and legal teams requiring audit trails. The stakes were high, and the solution space was constrained.

We defined success upfront. The new system needed to reduce permission-related support escalations, enable merchants to achieve GDPR-compliant access configurations, and see meaningful adoption within the first quarter of launch. If we shipped something that merchants didn't use—or couldn't figure out—we'd have failed regardless of how elegant the design was.

A System in Need of Change

The scale of the problem became clear once we started digging into the data. Shopify Plus merchants were operating with dozens or even hundreds of employees, each requiring different levels of access. But the permission system wasn't built for this complexity. It was built for a simpler time.

Existing permissions were both vague in their description, and gave users near all-encompassing ability to make changes.

The problems were concrete. A seasonal hire with "order access" could process refunds without oversight—and some did, intentionally or not. Customer service reps could view customer purchase histories, addresses, and payment details even when their role only required order status information. The permission to "manage products" included access to cost data and supplier information that should have been restricted to operations leads.

Merchants had developed workarounds, but none were good. Some simply limited who got admin access at all, forcing managers to perform tasks that should have been delegated. Others maintained spreadsheets tracking who should have access to what, manually auditing behavior after the fact. Many had just accepted the risk, hoping nothing would go wrong.

From a compliance standpoint, this was untenable. GDPR required that personal data access be limited to what was necessary for an employee's role. Shopify's binary permissions made that impossible to enforce natively. Merchants were technically non-compliant the moment they gave a CSR access to order data.

What We Considered (and Killed)

Before landing on our approach, we explored several alternatives. Each had merit. None were right.

More checkboxes. The most obvious path: expand the existing permission list. Add checkboxes for refunds, for customer data, for cost information. The problem was scale. Merchants already struggled to understand the existing permissions. Doubling or tripling the list would make configuration more error-prone, not less. Every new Shopify feature would require new permissions, and the list would grow forever.

Pre-defined role templates. We considered shipping a set of standard roles: "Customer Service Rep," "Warehouse Manager," "Marketing Lead." Merchants could assign templates instead of configuring permissions from scratch. But our research showed that every merchant's org structure was different. A CSR at one company had completely different responsibilities than a CSR at another. Templates would be either too rigid or too numerous to be useful.

Build a full RBAC system from scratch. Role-based access control done properly—with inheritance, role hierarchies, and custom attributes. This was the enterprise-grade solution. It was also a multi-year engineering investment that would require rebuilding foundational infrastructure. The timeline didn't match the urgency of the problem.

The insight that unlocked our approach: Shopify already had a flexible, conditional logic system that merchants knew how to use. Shopify Flow was built for automation—tagging orders, detecting fraud, triggering workflows. But Flow had access to all objects in Shopify, including users and permissions. What if we extended Flow to become a policy engine?

Designing Granular Control

The first challenge was clear: permissions needed to be more refined. Without granular control, businesses faced unnecessary risks—customer data exposure, unintentional refunds, and the reliance on external tools to enforce internal policies.

To address this, I led the design efforts in a two-phase approach:

• Introduce fine-grained access controls to restrict permissions more effectively.
• Leverage Shopify Flow's WYSIWYG interface to allow merchants to build custom policies tailored to their operations.

After conducting extensive interviews with over two dozen large-scale Shopify Plus merchants, a common theme emerged: conditional access was critical. A Customer Service Representative (CSR) should have access to certain order details but only within defined limits, Frontend Developers shouldn't have access to order or customer data at all, etc.

Layering in granularity allowed us to expand the scope of the existing, list-based approach

As an example, merchants wanted policies such as: "Allow refunds only within specific timeframes" or "Restrict access to orders above a certain value." My role was to translate these business needs into an intuitive, scalable permissions framework that ensured businesses could enforce their own internal policies natively within Shopify, reducing errors and eliminating unauthorized access.

Unlocking Flexibility with Flow

The challenge with predefined permission sets is that they become outdated as business needs evolve. A static system of checkboxes would quickly grow unwieldy, making it harder—not easier—for merchants to manage user access.

As Lead Designer, I worked closely with engineering and product leadership to integrate Shopify Flow into the permissions system. While Flow was typically used for tagging orders, detecting fraud, and streamlining fulfillment, we recognized its potential to revolutionize permissions. Since Flow had access to all objects within Shopify—including users and roles—it could serve as a dynamic policy engine.

Flow allows the merchant to set as many conditional checks on permissions as needed

By leveraging Flow, we enabled merchants to define intricate, logic-based policies within Shopify itself. Consider the following real-world example:

As part of my design process, I focused on ensuring these rules were easy to configure while maintaining flexibility. Rather than merchants relying on an ever-growing list of checkboxes, Flow empowered them to create their own policies, streamlining security and access control.

A Measurable Impact.

By shifting permissions from a static structure to an adaptive, rule-based system, we gave merchants unprecedented control over access and security. As Lead Designer, I helped create an experience that seamlessly integrated automation, compliance, and ease of use. The result? A self-sustaining permissions model that reduced risk while empowering teams with the right level of access—nothing more, nothing less.

The results were immediate and substantial. Within 90 days of launch, nearly 67% of interviewed merchants had adopted the new system. Key performance indicators highlighted its success:

What Happened Next

The most interesting part came after launch. Merchants started using the Flow-based permissions in ways we hadn't anticipated.

These unexpected use cases validated the core design decision: building on Flow's flexibility rather than shipping a fixed set of permissions meant the system could grow with merchant needs. We didn't have to predict every use case upfront.

The success of this project also unlocked follow-on work. The patterns we established for conditional access became a template for how Shopify approached permissions in other areas of the platform. What started as a targeted fix for enterprise pain became a foundational shift in how we thought about access control at scale.