A marketer’s contract ends. Nobody remembers to lock the door behind them.

Weeks later, someone notices they can still edit live Canvases, still pull segment exports, still see numbers they have no business seeing. 

Sound familiar? 

If you’ve run a Braze instance for any length of time, you’ve probably lived some version of this story. A freelancer whose access never got revoked. A client-side marketer holding onto edit rights they don’t use anymore. An old integration still running on permissions nobody remembers granting.

Braze rolled out granular permissions in its April 2026 release, replacing the older, broader access model with individual, toggleable controls across every part of the dashboard. This is a practical, admin-focused walkthrough of setting up Braze user permissions the right way: roles vs. permission sets, the moments that should push your team to run an access review, and how we structure access with client teams as a Braze implementation partner. 

What changed: Braze’s move to granular permissions

Managing who can see and touch what in Braze used to mean working with fairly blunt access levels. That changed this year.

Braze introduced granular permissions to give admins precise, workspace-level control over what each dashboard user can see and do. Instead of bundling access into a handful of broad tiers, admins can now toggle individual permissions across campaigns, Canvases, segments, user data export, PII visibility, billing, and the developer console. Dozens of specific actions, each one its own on/off switch.

That level of control matters because Braze accounts rarely stay simple. A team that started with three marketers and one workspace often ends up managing multiple brands, regional workspaces, agency partners, and integrations built by people who left the company two years ago. Granular permissions give you a way to match access to actual job function instead of approximating it.

Legacy permission strings like basic_access still work after the migration, so existing API and SCIM integrations won’t break overnight. Plan to update them to the specific granular permissions over time anyway.

Braze hasn’t published an exact rollout percentage for how many accounts migrated automatically versus how many need manual review. If that number matters for your compliance documentation, confirm it directly with your Braze account team.

Roles vs. Permission sets: Understanding the building blocks

Here’s where most admins get tripped up. Braze gives you two ways to grant access, and they solve different problems.

Permission sets are bundles of individual permissions tied to a subject area, such as “Developers,” “Marketers,” or “User Management.” They apply company-wide, across every workspace a user touches. Assign someone the Marketers permission set, and they get that access everywhere.

Roles are permission sets combined with specific workspace access. A role doesn’t just say what a user can do. It says where they can do it. That distinction is small on paper and enormous in practice.

Let’s break it down with two scenarios:

• A single brand account with one workspace rarely needs roles. Permission sets alone cover it, since there’s no workspace boundary to manage in the first place.
• A multi-brand or multi-region account, say separate workspaces for a Fashion brand and a Skincare brand, needs roles. A role called something like “Marketer: Fashion Brands” can grant the exact same permission bundle as a company-wide marketer set, but restrict it to only the Fashion Brand workspaces.

There’s a third layer worth knowing about: Teams. Teams control which audience segments and content a user can reach, not which actions they can perform. They’re a targeting boundary, not an access boundary, and they aren’t available on every Braze contract.

Here’s a simple rule of thumb. Use permission sets for company-wide functional access. Use roles the moment more than one workspace enters the picture. Reserve Teams for audience-level segmentation, not access control.

Step-by-step: Setting up granular permissions in Braze

Setting this up isn’t complicated, but the order matters. Skip a step, and you’ll be redoing the whole thing in three months.

Step 1: Audit before you build

Pull a current export of every dashboard user and their existing permissions before you change anything. Go to Settings, User Management, Company Users, Export Users. This gives your team a baseline to compare against once the new structure is live.

Step 2: Create permission sets

Head to Settings, User Management, Permission Sets, Create Permission Set. Name sets after function, not person. “Email Marketers” ages well. “Sarah’s Access” doesn’t. Sarah leaves eventually, and someone inherits a permission set named after her.

Step 3: Create roles for workspace-specific access

Go to Settings, User Management, Roles, Create Role. A role combines a permission set with the specific workspaces it should apply to. This is where multi-workspace accounts do the real work of matching access to structure.

Step 4: Assign to users

On a user’s detail page, you’ve got three assignment paths: select permissions manually, assign a permission set, or assign a role. Admins can mix approaches across different workspaces for the same user.

Step 5: Handle admin vs. limited user distinctions

Company Admins hold full company-wide authority, including deleting users. Workspace Admins hold full permissions, but only within a single workspace. One warning worth repeating: removing admin rights from a user without assigning at least one other permission locks them out entirely.

Here’s a quick example. A role called “Marketer: EU Workspace” bundles campaign and Canvas editing permissions, limited to a single regional workspace, versus a company-wide “Analytics” permission set built for reporting only staff who need visibility everywhere but shouldn’t touch a single send.

Step 6: Re-export and review

Pull a final export and compare it side by side against your Step 1 baseline before rolling the change out to the full team. This is the step most teams skip, and it’s the one that catches the mistakes.

Security and compliance triggers that should prompt a permissions audit

Over-permissioned accounts are a well-documented source of breach risk. Verizon’s Data Breach Investigations Report has tracked privilege misuse as a persistent incident pattern for years, with internal actors, not outside attackers, primarily behind it. Access that outlives its purpose is a liability sitting quietly in your account.

Granular permissions map directly onto least privilege requirements built into frameworks your enterprise clients likely already care about. SOC 2’s CC6.1                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               criterion requires restricting logical access to authorized users. GDPR’s data protection by design principle expects the same discipline. Auditors increasingly expect documented, reviewable access controls, not a blanket “everyone’s an admin” setup nobody can explain in a review.

So when should you actually run an access audit? A few concrete moments, not a vague “do this regularly” reminder:

• Employee offboarding or a role change. Auditors specifically sample terminated users to confirm access was revoked promptly.
• Onboarding a new agency, freelancer, or contractor who needs scoped access, not full access.
• Ahead of a SOC 2, ISO 27001, or client security questionnaire, when someone will actually be checking your work.
• After any campaign or Canvas incident traced back to unauthorized or accidental changes.

Braze’s permission list separates “View” and “Edit” rights for nearly every feature. That split makes read-only access possible for stakeholders who need visibility without edit risk. A CMO who wants to see performance data has no reason to hold edit rights on a live Canvas.

Agency handoff: Structuring access between client teams and Mavlers

Here’s a scenario we see constantly. A client’s internal marketing team needs full operational access to run their day-to-day work. An implementation or migration partner needs enough access to build and troubleshoot. Not enough to touch billing, manage users, or wander into unrelated workspaces.

Our recommended pattern is a dedicated “Agency Partner” role, scoped to only the relevant workspace or workspaces. It bundles campaign, Canvas, segment, and template permissions, while explicitly withholding company-level permissions like “Manage company settings” or “Create and delete workspaces.” That’s a role built for building things, not for running the account.

Take a client running parallel DEV, QA, and PROD workspaces. We’d typically get edit access in DEV and QA to build and test freely, and view-only access in PROD, so we can see what’s live without touching the send environment directly.

Offboarding discipline matters just as much on the agency side as it does on the employee side. When a project or contract ends, access should be revoked or transitioned immediately, not left dormant because nobody remembered to close it out.

One habit worth adopting: at project close, we give clients a short access summary listing exactly which permissions and workspaces were granted. It keeps the client’s own audit trail clean.

Wrapping up 

That brings us to the business end of this article, where it’s fair to say that granular permissions give Braze admins the precision to match access to actual job function across roles, permission sets, and the specific moments that should trigger a review. That precision isn’t a one-time setup task. It’s an ongoing discipline, especially for accounts working across multiple internal teams and outside partners.