Simplifying Powerful Permissions

Shopify's platform is renowned for its scalability and versatility, catering to a wide range of merchants from small businesses to large enterprises. However, as the platform continues to grow and evolve, so does its complexity. Managing this complexity, particularly in terms of permissions and access control, is crucial for ensuring security and efficiency.

This case study delves into the efforts to simplify the permission system for Shopify Plus merchants, aiming to reduce the cognitive load and enhance security for organizations managing multiple stores and significant revenue streams.

Plus merchants, who commonly manage anywhere from 10 to an excess of 100 million dollars of revenue a year, were running into a number of issues, identified over the course of a series of focused user interviews.

Below is an example of what permissions looked like at the outset of this project.

Some of the permissions were simply obtuse, like the checkbox labeled General, with no further explanation. Moreover, what's not shown, or described, is what actions a given checkbox would enable, or any nested information. As an example, Orders also provided access to:

• Customer Financials
• Exporting Order Data
• Refund Permissions
• Personal Customer Data

This lack of granularity and transparency led to one of two outcomes among merchants. They either resorted to writing complicated internal guidelines to ensure employees in a given role had a step-by-step process to reduce potential mistakes. Or certain roles would simply not be granted a specific set of permissions, resulting in them having to escalate issues to whomever did have the right set of permissions.

While not directly pointed out in the research interviews, this hinted at a larger underlying problem.

Layering in Granularity

The first and foremost issue of permissions we opted to tackle was their lack of granularity. The all-or-nothing approach to some (if not all) permissions caused ongoing issues such as data being visible to employees that shouldn’t have access, mistakes made in order refunds, or the need for third-party restrictions and policies.

In order to address this, we set out with a two-phased approach:

• Add policy-enabling granularity. This allowed merchants to bring permissions more in line with their internal usage and data-handling policies.

• Integrate with Shopify Flow.Flow is a WYSIWYG Editor for workflow automation, and Shopify Plus's poster child for enabling the multi-tiered complexity that merchants with large organizations bring to the table.

Among the more than two dozen large-scale Shopify Plus merchants merchants the most commonly occuring theme was the desire for conditional access policies. Certain team members, in certain roles, needed access to certain permissions. In addition to this, there might be more specific conditions that allow or restrict access depending on the user's role.

Over the course of these interviews, a library of sorts was formed to compile all the various forms of policies merchants had instated and were using in their day-to-day operations. Below is an example of a policy that we had come to describe as "medium" complexity.

While the granularity we were layering in wasn't able to accommodate every policy, we began to see a noticeable reduction in actions being taken by users that were considered "out-of-policy".

In practice, this translated into merchants being able to enact policies like “allow refunds within specific timeframes”, or allowing view access to orders below a certain monetary value. This effectively enabled organizations to replicate existing internal policies within the confines of the Shopify platform. Thus eliminating the possibility for mistakes, or providing access to things an employee shouldn’t have access to.

Replicating existing policies however, meant that we’d always be playing catch-up. Merchants would instate new policies, and express a desire for this to be enabled within the platform. Which ran the risk of quickly devolving into an ever-growing list of checkboxes, making permissions more and more dense, and less and less usable over time.

Leveraging Flow

One of the tools that Shopify Plus merchants got access to, is Flow; An automated, decision-making engine. Whilst predominantly used for automatically tagging orders, flagging potentially fraudelent transactions, or easing the burder of shipping, there was no reason it couldn’t be used for our permissions system.

More importantly, Flow had access to all objects within the platform, and users are effectively objects with a set of attributes in the form of roles. Meaning Flow already had the theoretical capacity to formulate policies, it just hadn't been thought of for that purpose up until this point.

Having access to every object within the platform meant that we could enable merchants to construct virtually all of their policies in-platform. Merchants were able to create intricate, custom policies directly within the platform. Each policy consisted of a series of true/false statements, that decided whether or not a given user within a given role could perform an action.

With the powerful decision-making engine that is Shopify Flow, merchants were quickly able to convert their internal policies to strictly enforced automated policies. We saw a near 100% adoption rate among interviewed merchant rates within the first 90 days. And rather than having to add to an endless series of checkboxes for new requirements, it became as simple as exposing existing commerce objects through the Flow API.

Rather than having to rely on workplace policies that needed constant oversight, Ability provided merchants with a self-serve, hands-off solution. If a given user or role shouldn’t be able to perform an action, they simply wouldn’t be able to iniate it.

With this, we were able to tackle all three high-level issues that surfaced through our user research, as well as hit (and exceed) key metrics to evaluate the success of our feature launch.

• Permissions remained powerful, but gave the merchant the level of control they needed to exercise caution. Rather than take away power, we opted to provide merchants with the tools to dictate exactly who could do what.
• Permissions became less opaque, and more transparent. We exposed the depths of access that a user would be granted access to in our first iteration, and expanded upon this with Flow.
• Permissions become more granular, in order to replicate the existing in-house policies that merchants had adopted.