Or why the most consequential product change this quarter isn't a chart or a model: it's a permissions system.
For most of the last decade, research platforms have been sold as if everyone on the team does everything. The researcher designs the study. The researcher programs it. The researcher fields it. The researcher analyzes the data. The researcher writes the report. One seat, one workflow, one set of permissions; usually "admin for everyone, because nobody wants to think about it on a Tuesday afternoon."
That worked when the research team was five people in a room. It doesn't work anymore.
The teams we talk to now look nothing like that. There's a brand insights group that designs studies, and a research ops function that fields them. There's a central analytics team that owns the coding dictionary across ten brands. There's a regional lead who can launch surveys in their own markets but not bill the corporate account. There's a contractor who builds questionnaires for two weeks and then needs to disappear cleanly from the platform. There's a finance partner who should see spend but shouldn't see respondent data. There's a data science team that consumes the API but never touches the UI.
All of those people need access to the same platform. None of them need the same access.
This is the reason we've rebuilt the permissions model in MX8 Labs: not as a visible feature you'll see in a product demo, but as a piece of infrastructure that changes what kind of organization can safely use the platform.
The Old Model Had One Knob
The binary admin model (user or administrator) is the default across almost every SaaS product. It survives because, most of the time, it is good enough. If everyone is trusted, and the stakes of any individual action are low, a coarse permission model is faster to build and faster to use.
The problem is that research platforms don't live in that world anymore. Four things have changed at once.
First, the stakes per action have gone up. Taking a survey live is now a direct spend decision against a sample provider contract. A wrong click in fielding can cost four figures before anyone notices.
Second, the data has become more sensitive. First-party audiences with millions of rows of customer data sit inside the same platform as demo surveys. Not everyone who can build a report needs to be able to export raw respondent data.
Third, the mix of people using the platform has broadened. In a typical enterprise engagement, we see brand teams, research ops, agencies, contractors, data engineers, and finance partners all logging in. Some have deep research backgrounds. Some are reading a dashboard and nothing else. The same permission grant that is correct for one of those users is wrong for another.
Fourth, the regulatory environment is less forgiving. Access to personal data increasingly needs to be both restricted and auditable. "The director trusts everyone on her team" is not a defensible control in a PIA or an audit.
Put those together and a single knob isn't a simplification anymore. It's a source of risk.
A Research-Shaped Permissions Model
The instinct, when you decide to build "proper permissions," is to copy whatever the last enterprise SaaS product you looked at did. Pick a few canned role names (viewer, editor, admin) and move on.
We didn't want to do that, because research has an unusual structure. A single object, like a survey, is edited by one group of people, fielded by another, reported on by a third, and sometimes coded by a fourth. A permission that says "can edit the survey" is too blunt; it collapses four different jobs into a single grant.
So the new model starts from the platform's actual resources. Projects, surveys, audiences, reports, report questions, report topics, coding dictionaries, coding labels, translations, insights, and todos each exist as their own resource type. Against each one, a role can be granted a specific action: read, create, update, delete, go_live, move, export. There are also separate actions for API and MCP access, so you can give a data engineering team programmatic access through the API without giving them a seat in the dashboard, or vice versa.
On top of that, constraints let you narrow a permission to specific values. A regional lead can be given the ability to create audiences, but only audiences below a certain price threshold, or only for a named project, or only on certain survey types. A finance partner can be allowed to read everything but update nothing except the fields that relate to billing.
Two system roles ship out of the box. account_member gives every new user the ability to do day-to-day research work (building surveys, managing audiences, creating reports) without touching account-level settings or taking anything live. account_admin lifts that to full control of the account. Most teams will never need anything beyond these two.
For the teams that do, custom roles can be defined at the account level and assigned per user. The same person can hold different roles in different accounts, because permissions are scoped to the account, not to the person. That detail matters more than it sounds: it means an agency with ten clients can keep its staff's platform access cleanly partitioned without asking anyone to maintain ten separate logins.
What This Changes Operationally
The practical effect of this change is that research operations looks less like an individual sport and more like a team one.
The research ops lead can say: contractors on this project get survey-builder access but not fielding access, and when the project ends, their role goes away. They can say: the insights team can read everything across the account, but only the named study owner can export raw data. They can say: agencies that come in for one study get a custom role that sees their own project and nothing else.
None of this is exciting, viewed in isolation. Nobody buys a research platform because it has a constraint system on its update permissions. But when you try to run a research function at scale without one, you run into the same problem over and over: the platform is either too open, which creates risk, or too closed, which creates bottlenecks. A real permissions model removes that trade-off.
It also changes what "auditable" means. Because permissions are additive and explicit, it's possible to answer, for any user, the question "what can this person do, and why?" by looking at the roles they hold, not by reading through a tangle of group memberships and shared logins. That matters for internal governance. It matters more for the DPO conversation when a study touches first-party data or a regulated population.
A Quiet Kind of Platform Maturity
I'm writing this up because I think the market tends to under-value this class of change.
When a research platform ships a new chart type or a new AI feature, it gets a launch post and a demo. Permissions changes don't demo well. There's no dramatic before-and-after. The best-case outcome is that nothing appears to happen, because the right people keep doing the right things, and the wrong people quietly can't do the wrong ones.
But in my experience, the teams that get the most out of a research platform over a five-year horizon are the ones whose platform grows up with them. The feature that lets you onboard a single researcher looks the same on day one as the feature that lets you onboard the thousandth. The difference is whether, behind the scenes, the platform has the bones to support a real organization: governance, delegation, segregation of duties, and auditability, without bolting them on as spreadsheets and tribal knowledge.
That's what this release is really about. It isn't a single feature. It's a statement about what kind of research operation we expect our customers to run, and how seriously we take the idea that software has to meet them where they are.
Where to Go From Here
If you're an existing MX8 Labs customer, your account has already been migrated. The two system roles cover most teams without any configuration, so if you don't need to think about this, you don't have to. Things will keep working.
If you do want to go further, the documentation walks through how to configure custom roles, what each permission does, and how to think about combining roles together. Start with Understanding Roles and Permissions for the conceptual model, then Managing Roles and Permissions for the practical walk-through, and the Permissions Reference when you need the full matrix.
The headline is boring, and it's meant to be. If the permissions system is doing its job, you'll forget it's there. That's the point.