How do you manage permissions and roles in Attio?

You manage permissions in Attio through a combination of workspace-level roles, list-level access controls, and object-level visibility settings. The system is straightforward for small teams but requires deliberate planning once you pass about fifteen users.

Workspace settings in Attio where you assign roles and manage team member access levels.

Understanding workspace roles

Attio provides three primary workspace-level roles: Owner, Admin, and Member. The Owner role is reserved for the person who created the workspace and has full control over billing, integrations, and workspace deletion. Admins can manage members, configure objects, and adjust workspace settings. Members can use the workspace but cannot modify its structure.

In my experience, most teams under twenty people only need one or two Admins and everyone else as Members. I recommend keeping the Admin count low. Every Admin can modify your data model, add or remove attributes, and change pipeline configurations. When too many people have Admin access, you end up with duplicate attributes, inconsistent naming conventions, and objects that nobody remembers creating.

The most common mistake I see is giving everyone Admin access because it feels easier during onboarding. It is easier on day one, and it creates problems by week three. Someone renames an attribute, someone else deletes a list view that the sales team relied on, and suddenly you're spending hours fixing things that shouldn't have broken.

List-level permissions

This is where Attio's permission model gets genuinely useful. Every list in Attio has its own access settings, and you can control who can view, edit, or manage each list independently. This means you can have a single workspace where the sales team sees their pipeline, the partnerships team sees theirs, and neither group accidentally modifies the other's data.

List permissions work at three levels: view access (can see the list and its records), edit access (can add, modify, or remove records from the list), and manage access (can change the list's structure, filters, and permissions). I typically set up lists so that the team that owns the workflow has edit access, their manager has manage access, and adjacent teams have view access.

For example, in a SaaS company workspace, the SDR team gets edit access to the prospecting list, the AE team gets edit access to the deals pipeline list, and customer success gets edit access to the renewals list. Everyone can see across lists for context, but they can only modify the records they're responsible for.

Object-level visibility

Beyond lists, you can control visibility at the object level. If you've created a custom object for something sensitive, like a fundraising tracker or an HR candidate pipeline, you can restrict which workspace members can see it at all. This is different from list permissions because it controls access to the underlying object and all its records, not just a specific view.

I use object-level restrictions sparingly. In most workspaces, transparency is more valuable than restriction. But there are clear use cases: an LP tracking object in a VC fund should probably be visible only to the partners and fund operations team, not to associates who are focused on deal sourcing. Compensation data, board materials, and investor relations work all warrant object-level restrictions.

When to restrict access

The question I get most often from clients is not how to set up permissions but when to start caring about them. My rule of thumb: if your team is under ten people and everyone is in the same function, you probably don't need granular permissions. Keep things open, move fast, and trust your team not to break things.

Once you hit fifteen to twenty users, or once you have multiple functions sharing a workspace, you need a permissions strategy. This is especially true when you have a mix of senior and junior team members. Junior SDRs should not have the same access as the VP of Sales when it comes to modifying pipeline stages, deleting records, or changing automations.

The triggers that tell me a team needs to tighten permissions:

• Someone accidentally deletes records from a shared pipeline
• Attribute definitions keep changing without a clear owner
• Teams are stepping on each other's list views and filters
• Sensitive data (revenue, compensation, investor details) is visible to people who don't need it
• New hires are overwhelmed by the number of objects and lists they can see

If any of those sound familiar, it's time to audit your permissions.

Setting up permissions for a growing team

Here's what I set up for clients who are scaling past twenty users. First, designate two or three Admins maximum. These should be people who understand the data model and are responsible for workspace governance. Typically this is the RevOps lead, the CRM owner, and maybe a technical co-founder.

Second, organize your lists with clear ownership. Every list should have one team that owns it. That team gets edit and manage access. Adjacent teams get view access. This prevents the common problem where twelve different people are all making small tweaks to the same list's filters and layout.

Third, use list attributes versus object attributes strategically in the context of permissions. Object attributes are visible everywhere a record appears, so they should contain universally relevant data. List attributes are scoped to a specific list, which gives you a natural permission boundary. If the sales team needs to track a "competitor mentioned" field that nobody else cares about, make it a list attribute on their pipeline list rather than an object attribute on Companies.

Fourth, review permissions quarterly. Teams change, roles shift, and what made sense six months ago might not make sense now. I build a quarterly review into the CRM governance process for every client I work with.

Permissions at scale: 50+ users

When you're approaching fifty users, permissions become a governance exercise, not just a settings toggle. At this scale, you need documented policies about who can create new objects, who can add attributes, and what the approval process looks like for structural changes.

What I recommend for larger teams:

Create a "CRM Council" of three to five people who approve structural changes. This sounds bureaucratic, but it prevents the attribute sprawl that kills CRM adoption. Without this, you'll end up with six different versions of "Company Size" as an attribute because three different teams each created their own.

Use Attio's team features to group workspace members. Instead of managing permissions user by user, assign permissions to teams. When someone joins or leaves, you update their team membership and permissions follow automatically. This is dramatically easier to maintain than individual permission assignments.

Document your permission model. A simple spreadsheet showing which roles can access which objects and lists saves hours of confusion. I've seen workspaces where nobody could explain why certain people had access to certain lists, and untangling that after the fact is painful.

Common permission mistakes

The first mistake is over-restricting too early. A five-person startup does not need the same permission model as a fifty-person sales org. Start open, restrict as you grow. The overhead of managing granular permissions on a small team outweighs the risk of accidental changes.

The second mistake is under-restricting as you scale. I've worked with teams of forty people where every single person had Admin access. The workspace was a mess: duplicate attributes, abandoned custom objects, pipelines with stages nobody recognized. Cleaning that up took longer than setting up permissions properly would have taken in the first place.

The third mistake is using permissions as a substitute for training. If people are breaking things, the answer is usually better onboarding, not tighter restrictions. Permissions should protect against honest mistakes and enforce data governance, not compensate for a team that doesn't understand how to use the tool.

The fourth mistake is not having a clear owner. Every workspace needs one person who is responsible for the permission model. When "everyone is responsible," nobody is, and the permission model drifts until it's incomprehensible.

Building a permission strategy that lasts

Permissions also extend to your integrations and API access. API keys and integration connections inherit access levels, so consider who controls these. An API key created by an Admin can modify anything in the workspace, including objects and attributes that should be locked down. For teams with custom integrations, I recommend creating a dedicated integration user (if your plan supports it) and scoping its permissions appropriately. Check Attio's help documentation for the latest on integration-level permission controls. Document every active API key, what it's used for, and who created it. Rotate keys regularly, especially when team members leave.

The best permission model is one that your team doesn't think about. It should feel natural: people see what they need, can edit what they're responsible for, and aren't blocked from context they need to do their jobs.

Start with the principle of least privilege, but temper it with practicality. In a CRM, transparency generally matters more than restriction. People need to see customer data, deal context, and relationship history to do their jobs. Restrict write access before you restrict read access, and restrict structural access (changing the data model) before you restrict data access (modifying records).

If you're setting up a new workspace or cleaning up an existing one, the permission model should be one of the first things you design, right after your data model. Attio makes this straightforward if you plan it early. Getting this right saves significant pain later.