Scaling Your Martech Tools With Roles and Permissions

When people think about high-performance martech systems, roles & permissions are usually not top of mind. This misconception is because the administration of tools is not the sexiest topic for aspiring growth marketers and user acquisition managers. Often, permissions are an afterthought in setting up or re-inventing a marketing technology stack. 

But in my experience, these two facets - and the successful management of both - are the building blocks to scale marketing tools across an organization. 

To be clear, when I talk about roles and permissions, I am referring to two concepts rooted in IT administration: 

1) Means of Access to a Tool: This refers to how easy it is for a user to access a tool. It includes questions like, "Does the tool have SSO enabled?" "If so, is it enforced?" "What just in time permissioning (JIT) level is set by default?"

2) Privileges Needed to Perform a Task: This refers to the "level" of permission to perform various tasks in a tool.

When it comes to marketing tech management, how easy it is to enable, enforce, control, and manage #1 and #2 dictates how easy a company can scale its marketing technologies. Most tools do a reasonably good job of providing *some* controls out of the box.

A collection of standard martech tool UIs that demonstrate how easy or hard it can be to add users with various permissions. The roles different tools make, how granular the controls are for each feature, and how painful it is to add/remove or edit users are all factors that dictate the scale-ability of a tool in the wild.

The gold standard for "roles and permissions" is AWS IAM, which gives high granularity to every aspect of every product across the AWS ecosystem.

Highly granular roles and permissions for each feature of each product in the AWS ecosystem makes it easy for teams to manage security with high fidelity. This is part of what makes it easy for companies to use AWS broadly. They can grant security to very specific permissions without compromising the integrity of their entire toolset. Some tools in the martech space have modeled their permissions like AWS. Others are very far behind. There are some best practices you can take with such vendors which we'll talk about below.

Typical Lifecycle of Tool Usage

When companies first buy marketing technology tools, they often don't have very many users. Even more often, they are young startups that are looking to move fast. So, a young company will buy tools, stand them up, and then quickly forget about what comes next. There is no problem with this. Companies need to balance moving fast and managing process. As time goes by, however, failing to control your user roles makes these tools un-scaleable.

Over time as a company grows and more users adopt the tool, two outcomes can occur: a company can take control of its marketing technology with a well-defined process built around each tool's roles and permissions, or they can do nothing and let the liability grow.

Why it Matters

Roles and permissions don't matter that much for companies with less than ten employees using individual tools or a system of tools. However, as a company scales to hundreds of users on a particular marketing stack, it matters much more. This is because as more people are exposed to different features in a tool, the chances for negligence (user wasn't appropriately trained), incompetence (user was trained, but isn't qualified to be doing the task), or nefariousness (user knows what they are doing and is actively doing something wrong) grows.

Let's consider a few examples. 

I really like Branch's permissioning UI because 1) They make it sufficiently granular, 2) They have standard roles that you can apply out of box, 3) they allow you customize a user or even a role, and 4) They have tool tips explaining what each permission is for. If you're reading this and looking for a "best in class" example of how to scale usage of a tool, look no further.

Attribution providers usually provide online access to create deeplinks, examine attribution data and associated user metadata, and compare this in a funnel to custom event data.  An engineer who has the incorrect role or permission could modify the app settings to redirect users to the wrong app or website. A marketer who wasn't trained on creating deep links could set the incorrect analytics tags, creating a headache for the analytics team to fix. Worse, an employee who is leaving an organization could export sensitive customer data before or after leaving (depending on SSO enforcement).

In a messaging platform, the stakes are even higher. A user of a CRM system with unfettered access to IPs and APIs could send emails incorrectly to customers, or worse, tarnish the IP credibility of the business if those emails go to spam. And like with an attribution tool, export features could allow users to download sensitive customer data when they don't need it.

And of course, these rules matter most for data platforms and data in ingestion tools where sensitive user data is stored. CDPs/CDIs and data aggregators like Snowplow,  Lytics, Segment, and mParticle, have UIs that grant broad ability to download, access and export data to other 3rd parties.

Best Practices for Managing Your Tools

So, how do you maintain safety while still empowering users with these tools? Here are the best practices I follow and give to customers when I find permission and role issues in a martech system:

  • SSO: Setup SSO and enforce it if possible. Require vendors without SSO to build it as a part of your next contract renewal. This should be non-negotiable!
  • Martech Admin: Elect one person as the administrator of your martech stack. This should be the person who really fundamentally understands how things work or should be somebody on IT who is responsible for adding users. A defining feature of the "admin" role in all modern martech tools is that the admin can add other users. It's important that you only give this permission to a limited number of users, otherwise you invite unlimited liability since other admins could invite users with incorrect permissions and there would be no control mechanism in place to prevent this.
  • Administration Process: Beyond having an admin, develop a request or intake process by which users must request access. Even if it's dead simple. Implement something so that there is a check and trail of who gets access to what. This will make it easier to update users in the future, and make corrections when mistakes are made.
  • Quarterly Audit: Audit your tools every quarter to check the permissions of different users, ensure rogue admins haven't popped up, and to remove users who don't need access to the tool.
  • Default Roles: Develop a "default permissions" role for each tool. Describe how to set that default for each tool so that it becomes easy to offload this process to IT or manage internally in your team.
  • Implement an Operating Model: Operate with a "Least Needed Privilege" model, where users get permissions in the tool at the most basic level to do their job and nothing more. Higher access levels to tools should be treated as a privilege, not a right, earned through proper demonstration of understanding and training.
  • Build Custom Tools to make it easier and faster.

Case Study in Custom Permissioning with Braze

Recently, I worked with a customer to clean up their Braze permissions. Like so many other customers who have used Braze for years, we had three specific problems:

1) SSO wasn't enforced. Anyone with a user name and email account could log in. Even ex-employees.

2) Admin Proliferation made Permissions Ineffective: They have seven different properties or "app groups" using braze. This meant that the same process needed to be repeated seven times within the user permissioning console. Since the UI had no way to apply a standard role easily across all groups at one time, you can guess what happened: almost all users were admins. Since most employees were admins, there was a culture of "anyone adding anyone." This meant that there were virtually no controls over who could access the platform's sensitive or technical parts.

3) No SOP: There was no standard operating procedure or process for giving users permission and approving users who needed heightened privileges.

So what was our approach? First, and perhaps most obvious, we enabled SSO. Second, we cleansed app groups that weren't needed. Third, we downgraded all users to "limited" and required users to fill out a form if they wanted special permissions that were considered "sensitive," like the ability to edit our IP configs or export user data. Users who didn't fill out the form were deleted after 14 days. In the end we took 150+ admins down to 6, purged about 200 users and reset expectations across the company on how to get access to Braze.

Despite our success executing, we still struggled with the fact that the UI for Braze made it very challenging to add roles and permissions for our users. There are 19 different features that each allow access. These 19 permissions are horizontally scrollable, and we had to set them manually for 6 other groups. That was 133 buttons to click every time we needed to add a user.

On one hand, I love the nuanced ability to edit permissions by every fathomable feature. On the other hand, the horizontal scroll is brutal. In order to customize 19 permissions per app group, we built this custom script that allows you to quickly apply a standard role to the user.

The solution was to build our own chrome widget, which injects this javascript into the page. This in turn would downgrade the user, automatically deletes the user from all the app groups, adds them again, and then sets the "default" permission level for each element. In this case, our "default" was just what we agreed to internally and was converted into an array to make it easy to update in the future.

Automation like this will grow as more enterprises grapple with how to manage hundreds of users in tools that expose sensitive data. Platform APIs do exist, like mParticle's, but even this doesn't allow access to add, remove, and update users associated with the platform. If tools do develop these APIs, then Terraform would allow automated state files to exist that capture the "permission state" of the entire organization. As users enter and leave an org, based on their role, all martech tools could be updated in real-time to give them the privilege they need.