Roles, Plans, and Access — The Captivar Permission Model

If the rest of the docs are about how to do things, this one is about why certain things work the way they do. Once you have the mental model of Captivar’s access system, every permissions question becomes obvious — and you can predict what will happen in situations the procedural docs don’t cover.

The three-axis access model

Access in Captivar is controlled by three independent things stacked on top of each other:

1. Your role on the account — Owner, Admin, or Member
2. Which sites you have access to — all of them, or a specific subset
3. Whether you’re an agency user or a client user — agency users work the platform; clients see one site’s portal

These three things combine to define what you see and what you can do at any moment. Change any one of them and the other two still apply. This is what makes the model flexible — and also what makes it easy to get wrong if you only think about one axis.

Axis 1 — Account roles

Three roles inside an agency account. Each role inherits from the one below.

Owner

One person per account. The account creator by default. Controls billing, can transfer ownership, can delete the account. The only role that can downgrade the plan or cancel.

Admin

Trusted operators. Everything except billing. Can invite other team members, configure receptionists, build forms, work the pipeline, change branding. Cannot touch payment methods or cancel.

Member

The “doer” role. Reads and works the platform, doesn’t configure it. Most agency staff fall here — account managers, intake staff, virtual assistants. Members are the only role that can be scoped to specific sites (covered in axis 2).

The roles are designed to be a strict hierarchy. Anything a Member can do, an Admin can do. Anything an Admin can do, an Owner can do. There are no “Admin can do X but not Y while Member can also do Y” exceptions — that complexity makes systems unpredictable.

A common mental model: Owner pays, Admin configures, Member works.

Axis 2 — Site-level access

Independent of role, every Member has an explicit list of sites they can see. By default, the list is empty — a newly invited Member sees nothing until you grant them access.

Admins and Owners always see every site automatically. Site-level access only applies to Members.

This is the axis that protects client data. A Member managing the dental practice’s account should not be able to see the law firm’s leads, even though both are on your account. Site-level access lets you partition Members per client.

Three site-access patterns work for most agencies:

• All sites. The member sees everything you do. Use for trusted internal staff who need cross-portfolio visibility.
• Specific sites. The member sees only the sites you explicitly grant. Use for client-specific account managers, contractors, and staff who shouldn’t see unrelated clients.
• One site, time-bounded. A contractor needs access to one site for a project. Grant the site, remove access when the project ends. This is what suspension is good for — keeps the historical contributions but removes access.

Axis 3 — Agency user vs client user

Captivar serves two fundamentally different kinds of users.

Agency users are you and your team. You see the full agency dashboard — sites you manage, leads you work, configurations you control. You log in at app.captivar.com. Your view shows multiple sites if you manage multiple. You can switch between them.

Client users are the businesses whose sites you manage. They see a different surface entirely — a portal scoped to their one site, branded with your agency’s identity, designed for reading and not configuring. They log in at portal.captivar.com (or your custom subdomain). They have no site switcher because they have only one site.

The two surfaces are deliberately separate. A client can never see an agency dashboard, even if you somehow gave them the URL. An agency user can preview the client portal but cannot accidentally end up “stuck” in it.

The two user types are stored separately in our system. A client added to “Brightside Dental” is not a Member of your agency account — they’re a Client of that specific site. You can be both an agency user on your own account and a client on someone else’s account using the same email; the system disambiguates by URL.

How the axes combine — a few worked examples

The model becomes intuitive once you walk through a few real scenarios.

”Lisa is my new account manager handling three clients”

• Role: Member (she doesn’t configure, she works)
• Sites: Just the three clients she manages (not all)
• User type: Agency user

Lisa logs into the agency dashboard. She sees three sites in the site switcher. She can read, work the pipeline, and respond to escalations across all three. She cannot see the other 12 clients on the account, cannot configure the receptionist, and cannot change branding. If she leaves, you suspend her and revisit in 30 days.

”Tom is my technical partner who needs full platform access”

• Role: Admin (he configures things)
• Sites: All (Admin gets all by default)
• User type: Agency user

Tom logs in and sees the full agency portfolio. He can install trackers, configure receptionists, build forms, set up calendars, manage other Members. He cannot change the plan or cancel — that’s Owner territory. If you’re hit by a bus, he can keep the platform running but cannot wind it down without Owner help.

”Dr. Patel is the dentist at Brightside Dental — one of my clients”

• Role: No agency role at all
• Sites: Just Brightside Dental, as a client
• User type: Client user

Dr. Patel logs in at portal.youragency.com. He sees a portal showing Brightside Dental’s visitors, leads, bookings, and reports — branded with your agency’s identity. He cannot see the agency dashboard. He cannot see any other client of yours. He cannot configure his own site’s receptionist (you do that for him).

If Dr. Patel sends an invoice to his office manager so she can also see the portal, that office manager becomes another client user on Brightside Dental, again with no agency presence.

”I want my brother to help me with billing temporarily”

• Role: Admin (cannot manage billing) → not enough
• Role: Owner (only one Owner per account) → can’t have two

The right answer: transfer Owner to him temporarily, do the billing work, transfer back. This is a deliberate friction. Billing access is intentionally bound to a single person to prevent confusion about who’s accountable for the account.

Axis 4 (sort of) — plans

Plans are the fourth thing affecting what you see and do, even though we don’t think of them as a “role.” Plans gate features regardless of your role:

• The site count limit is per-plan. An Owner on Free still cannot manage 10 sites — the plan caps it.
• Custom branding is per-plan. An Admin on Starter cannot turn branding on; only an Owner upgrading to Agency can.
• AI message quotas are per-plan. Once you hit the cap, the receptionist disables for everyone on the account until reset, regardless of role.

Plans live underneath roles. You can be the Owner of a Free account and have less platform power than a Member of an Enterprise account at a different agency.

This is by design: roles describe who can do what within an account; plans describe what an account can do. They compose multiplicatively, not additively.

What the model is designed to prevent

A few problems this model is shaped to avoid:

• Accidental cross-client data exposure. Site-level Member scoping is the main defense. A contractor brought in for one project can be scoped tight enough that they cannot leak data from clients they shouldn’t even know about.
• Configuration churn from too many cooks. Most agency staff are Members, not Admins. This keeps configuration changes (forms, receptionist, calendars) limited to people who own the outcome.
• Lost ownership. Single-owner accounts ensure there’s always exactly one person accountable for billing. Transfer is deliberate, not accidental.
• Visible Captivar branding. The agency-user vs client-user separation ensures clients never see “Captivar” even when their portal is functionally inside our infrastructure.

What the model intentionally doesn’t try to solve

Some things this model doesn’t cover, on purpose:

• Granular per-feature permissions. You cannot say “this Member can manage forms but not configure the receptionist.” Members manage all of one and none of the other based on whether you trust them to be Admins or not. Adding more granularity made the model dramatically less predictable in testing; we chose simplicity.
• Cross-agency collaboration. A Captivar user cannot be a Member of multiple agencies at once with the same login. They can sign up for additional accounts with different email aliases, but each account stays isolated.
• Audit-grade access controls. We log significant access events (covered in the Team page’s Activity tab) but we don’t offer compliance-grade audit logging or SAML/SSO yet. Enterprise customers with these requirements should reach out — we can configure both, but not via self-serve.

What happens next

The three concept articles together — this one, plus the eventual articles on the Drift/Net/Haul vocabulary and the Sites/Sessions/Visitors data model — form the mental scaffolding under the rest of the docs. The remaining work is the Weekly Catch Report, which closes out the communication section, and the troubleshooting articles for when something doesn’t work the way these docs describe.