Scaling Fivetran's Enterprise Permissions

Context

Fivetran's legacy permissions model wasn't built for enterprise scale. Permissions were tied to destinations, which meant any user with access to a destination could access every connector inside it. Large customers worked around this by spinning up new destinations to silo access. This was a brittle, manual workaround. As enterprise interest grew, the need for a real governance model became critical.

Our goal was to support secure, scalable access across complex org structures. This would enable large customers to delegate ownership, restrict access to sensitive data, and onboard users efficiently. RBAC wasn't just a security fix. It was a foundational shift that enabled Fivetran to sell into larger, more regulated organizations.

Challenges

Fivetran's original permission model was simple: six generic roles with limited customization. That worked for small teams but collapsed under the complexity of enterprise organizations.

• No way to assign access at a granular level
• Vague role definitions and poor visibility
• Inherited permissions led to confusion and over-granted access
• Admins couldn’t delegate. Everything ran through them

To complicate the design challenge, I discovered that governance needs varied wildly. Some customers separated production and staging; others enforced connector-level restrictions, PII obfuscation, or SCIM/SAML integration. Contractors needed access to a single connector without visibility into anything else. Destination admins needed control without account-wide access. And usage had to be tracked not just per user, but per team. I wasn't designing for edge cases, I was designing for the reality of enterprise complexity.

Solution

The real challenge wasn't designing a better screen. It was defining a permissioning system that could scale across hundreds of users, dozens of data sources, and highly segmented teams. The old model couldn't express what customers needed. We had to rethink how roles, resources, and organizational structures related to each other and build a system flexible enough to support all of them.

We deliberately chose an explicit access model with no silent inheritance and no automatic escalation to match enterprise expectations around privacy and control. That meant solving for complex scenarios: contractors who could only touch one connector, team-level access without account-level privileges, and admins who needed visibility without overreach.

The outcome wasn't just a new flow. It was a new foundation. We introduced clearer out-of-the-box roles, a custom role builder, and a new Teams feature that let admins group users and delegate access more efficiently. Once the system was in place, we redesigned the Add User experience to reflect it, making role and resource assignment easier, more predictable, and scalable.