
Members are assigned to permission sets to control what they can access. A member can belong to one set, several sets, or none — though a member with no permission sets will have no access beyond basic workspace visibility.
It is completely normal and expected for a member to be in two or more permission sets simultaneously. This is not an error or an unusual configuration.
Common reasons to assign multiple sets:
Role + project access. A member's base set (e.g. "Field Operator") gives them workflow submission access. A project-specific set (e.g. "Q3 Audit") adds temporary read access to a specific analytics view for the duration of that project. When the project ends, you remove the project set without touching their base access.
Graduated access. A new hire starts with a restricted set. As they take on more responsibilities, you add a broader set rather than recreating their access from scratch.
Cross-functional members. Someone who works across departments may legitimately need the access levels of two different team sets — and combining them is cleaner than building a one-off hybrid set.
When a member belongs to more than one set, their effective access is the broadest combination across all their sets:
During the invitation flow, you choose which permission set they start in. This sets their initial access level. You can assign additional sets at any time after they accept the invitation.