Give a contractor limited account access

Member. Reads everything in the workspace — campaigns, numbers, drafts, plans, media, connection status — drafts changes, and uses the agent. Cannot approve one.

Admin. Everything a member can do, plus approving, rejecting and reverting drafts, connecting and re-syncing ad accounts, writing approval rules, and inviting people.

Owner. Everything an admin can do, plus raw platform requests, the plan, and the workspace itself.

A member can hold more than one role, and the split is the useful part: a member does the work and an admin decides it happens. That is the arrangement most people mean when they say limited access, and it is one role rather than a configuration exercise.

Roles gate actions, never visibility of state. A member who cannot connect an account still sees every card and every status on the connections page, because the half that tells you what is happening is not the half that changes it. Where an action is not a member's, the button says who to ask rather than disappearing.

This is the part people expect to work differently, so it is worth being blunt.

There is no per-account permission inside a workspace. A member of a workspace reads every connection and every ad account in it. If a contractor should not see one client's numbers, that client's accounts belong in a different workspace.

That is not a gap being apologised for — it is the same boundary the whole product is built on. Every query is scoped to the active workspace rather than to your account, a credential is bound to one workspace for its whole life, and no capability accepts a workspace to name. One account can belong to several workspaces and the switcher follows you; a new workspace starts empty, with its own connections, drafts, plans and credentials, and nothing shared with the one you came from.

So the design question is the one from the start: which accounts belong in the same room. Answer that and the access question mostly answers itself.

If the contractor will point their own AI at the accounts, they mint their own credential rather than using yours. One credential per client is the rule, because a shared one cannot be revoked without taking down everything else holding it, and the last-used stamp stops meaning anything the moment two things use it.

Scope it as narrowly as the job. Every credential carries read; draft is the addition that lets an agent prepare work rather than describe it; approve is opt-in at the mint and off by default. For a contractor, read and draft is the pairing that matches the member role, and approve is the one to leave off.

Then the thing that catches people out: a credential dies with the membership that minted it. Membership is re-read on every call, not checked once on the day the credential was created. Remove the contractor from the workspace and every credential they minted stops answering in the same moment, with nothing to revoke by hand.

That is a good default and a bad surprise. It means offboarding is one action. It also means anything that has to outlive one person — a reporting job, a scheduled export — should be minted under an account that is not going anywhere, and the name should say so.

The arrangement any of their work sits inside, stated once: your connections read your accounts, a change is written as a draft on the record with the state it would change from and the checks it passed, applying it is gated on approval — by you, or by a rule you wrote — and no platform write reaches a customer account until that platform has granted write access. Applying a cleared change to a platform is in private beta.

A seat is a member of the workspace, and how many a workspace may hold is a plan entitlement.

Inviting somebody sends an email with a link; accepting it puts them in the workspace with the role the invitation named, and the link also lets them decline. An invitation that is waiting reserves a seat — otherwise five invitations on a three-seat plan would be a queue of surprises — and accepting one converts the seat already reserved rather than taking a second.

The count is re-checked at the moment of acceptance rather than only when the invitation was sent, because a plan can be downgraded while an invitation sits in an inbox. If there is no room the acceptance is refused rather than the workspace quietly going over.

Two things, and both are one switch.

Approving. Keep the admin role, or keep it with one person who is not doing the work. If the volume makes that impractical, a narrow approval rule is better than a second admin: a rule clears pauses and budget or bid decreases below a cap it states, and never an increase, so it takes the safe half of the load and leaves the rest.

Raw platform requests. Owner-only and off by default. It reaches a platform's own API for endpoints Tempio has not normalised, and a mutation through it is a change request no rule may ever clear. There is rarely a reason for a contractor's workspace to have it on.

Remove the membership. That kills their credentials in the same moment and ends their access to the workspace.

Read what is queued. Anything they drafted is still at the gate and still yours to approve, replace or reject; removing the person does not remove the work.

Read the record. The log holds an actor by name rather than a link to a user account, so what they did stays readable after they are gone — including, for each approval, which authority cleared it and whether the approver was the actor that drafted the change.

If the handover is to somebody else rather than to nobody, the client handover template is the document version of this, and Audit an ad account after a bad week is the read to do if you are arriving rather than leaving. For the machinery that stops work rather than people, Spend caps and kill switches.