Team and roles: giving your people the right access without the wrong risk

Access control is one of those things that only becomes visible when it's wrong — the day a well-meaning teammate changes a setting they shouldn't have, or the day you realize the one person who could manage the account has left. A good role model prevents both without making you think about it. The goal is simple to state and surprisingly easy to get wrong: let your people do their jobs freely, keep the levers that move money and access in trusted hands, and make it impossible to accidentally lock yourself out. This guide is about how a clean two-role model achieves all three.

Two roles, one clear line

The most durable access model for an affiliate program is not a sprawling permission matrix; it is two well-drawn roles with a clear line between them.

An admin has full access and governs the account. Admins control account-wide settings, own the billing relationship, manage integrations, and are the only people who can invite, edit, or remove team members. They are, in effect, the people responsible for the account, not just people who work in it.

A staff member — the right role for most operators, including account managers — can see everything and make day-to-day edits, but cannot change account-wide settings or touch the roster. This is the crucial design choice: staff are limited in what they can change, not in what they can see. An account manager needs to pull any report, check any campaign, and work their partners without friction; what they don't need is the ability to reconfigure the account's fundamentals or manage other people's access.

That "view everything, change the sensitive things carefully" split is what makes the model work in practice. It means handoffs and coverage between teammates stay easy — anyone can step in and see the full picture — while the settings that could quietly break the program stay with the people accountable for it.

Why "see everything" is the right default for staff

It is tempting to think tighter is safer — lock staff out of anything they don't strictly need. In a collaborative operations team, that instinct backfires. When a teammate is out and someone has to cover their partners, an over-restricted role means the cover person can't see what they need and the work stalls. Visibility is rarely the risk; configuration is. A staff member reading a report they don't normally touch costs you nothing. A staff member changing a global setting they don't understand can cost you a lot. Drawing the line at change rather than sight is what keeps a team fluid without exposing the account.

Assigning ownership: the account manager

Roles say what someone can do; ownership says what they are responsible for. A well-built platform lets you assign a staff member as the account manager on specific partners, so each operator has a clear book of business — and so partner lists and performance views can be filtered to one manager's partners. This is how a program of any size stays organized: every partner has a name attached, and every operator knows which relationships are theirs. It works hand in hand with how you add and manage affiliates, where that ownership is set.

Onboarding with the right paperwork

Bringing someone onto the account is more than sending an invite. For the people who will act as your account's authorized contact — usually admins — you often need them to accept the current terms and privacy policy and sign a data processing agreement before they start. A mature platform can require exactly that: a new member is stopped on their first login until they have accepted the agreements and signed the DPA, producing a timestamped signed copy. It's the sort of governance step that is trivial to build into onboarding and painful to chase down after the fact — especially when a previous signatory has left and you need a fresh, valid agreement captured under the right person. Being able to require it per person, defaulting it on for admins and off for operators, is the kind of detail that separates a platform built for real businesses from one built for demos.

Suspend versus remove

People come and go, and the platform should distinguish between "gone for now" and "gone for good." Suspending a member blocks their sign-in while keeping their account and everything they created intact — the right move for someone on leave, an offboarding in progress, or a security concern you want to act on immediately and investigate later. Flip it back and they're reinstated exactly as they were.

Removing a member revokes their access entirely, but — importantly — deletes nothing they created. Their work stays in the account, and you can re-invite them later with the same email if the relationship resumes. This matters because the alternative, where removing a person tears out their data, makes offboarding destructive and discourages you from doing it cleanly. Access and data should be separable: cutting someone's access should never cost you their contributions. Every one of these changes — invites, role edits, suspensions, removals — should land in the account's activity log, so the history of who had access when is always answerable.

The guardrails that save you from yourself

The most valuable parts of a role model are the things it won't let you do. Three guardrails matter.

You should not be able to change your own role, because the classic self-inflicted disaster is the sole admin who accidentally demotes themselves and can no longer manage the account. You should not be able to remove yourself, for the same reason. And the account should refuse any change that would leave it with no admin at all — the "last admin" protection — so there is always at least one person who can manage the team and the settings.

These sound like edge cases until one of them happens to you. A program that lets you strand yourself is a program that eventually will. Guardrails that make lockout structurally impossible are worth more than any amount of careful process, because they work even on the day everyone is moving too fast to be careful.

Roles in practice

The pattern that works for most programs is to start conservative and promote deliberately. Keep one or two admins — whoever owns the account, the billing conversations, and the platform settings — and make everyone else staff, each assigned as account manager on the partners they own. Because staff can see everything, this costs you no operational flexibility; it simply keeps the account's fundamentals in a small, accountable group. As the team grows, you promote to admin only when someone genuinely needs to govern the account, not merely to operate in it.

This same least-privilege instinct should extend beyond people to systems: just as you grant staff the access their job needs and no more, you scope API keys to the capability each integration requires. And the access you grant sits on top of the account you set up at signup, whose billing and ownership are covered in the signup and billing guide.

Recovering access when someone is locked out

Real teams lose access at the worst times — a forgotten password before a big campaign, a lost authenticator device the morning of a client call. A team model is only as good as its recovery paths, and those paths should live with the admins rather than requiring a support ticket to the vendor. An admin should be able to send a locked-out member a link to set a new password, or clear a member's multi-factor enrollment so they can register a fresh device at their next sign-in, without anyone waiting on an external queue. Keeping recovery in the account's own hands is what turns a lockout from a lost afternoon into a two-minute fix.

The important nuance is that recovery is an admin capability, not a self-service one, precisely because resetting someone's access is exactly the kind of powerful action that needs to sit with an accountable person and land in the audit trail. The same instinct that gates configuration and key management gates recovery: give the people responsible for the account the tools to keep their team working, and record it when they use them.

What to look for

Judge a platform's team model by whether it makes the safe thing easy and the dangerous thing impossible. Is the role split clear enough that you can delegate without a meeting? Can staff see enough to cover for each other? Can you require the right agreements on onboarding, suspend without destroying data, and remove without losing contributions? And — the tell — does the platform stop you from stranding yourself with no admin? A model that clears that bar lets you build a team behind your program with confidence.

Governing who can do what is part of running a program you can trust at scale. See how account-wide controls — including how much autonomy your AI assistant is given — fit together in the AI feature overview, and a demo will walk the role model through on a real workspace with you.