Team
Invite colleagues into the workspace, understand what each role can do, and keep every change attributable to a person.
After this page you can bring a colleague into the workspace, know what they will be able to do before you send the invitation, and keep the activity log worth reading. A workspace belongs to a business, not to a login.
Team in the console is where invitations are sent, resent and withdrawn, and where you can see how many seats your plan leaves. How many seats that is depends on your plan — see pricing.
Who can administer a tracking workspace
Everything behind the tracking console asks one question of whoever is signed in: do they hold an owner or admin seat on this workspace, or on any workspace above it? Anything else is refused.
| Role | In the tracking console |
|---|---|
| Owner | Full access, including the plan, the wallet and the team. A workspace has exactly one owner. |
| Admin | Full access to day-to-day operation: campaigns, routing plans, buyers, targets, publishers, numbers, webhooks and API keys. |
| Agent | No access to this console. An agent seat is a seat on the wider account, not authority over a tracking workspace. |
Inviting somebody
- 1
Choose what you are inviting
Agent is a person who will work inside this workspace and takes one of your plan's seats. Sub-agency is a business that will run its own team below you — it does not take a seat, and its own people are invited by them.
- 2
Send it
Their name (or the agency's), and an email address. Send invitation emails them a link. Each invitation is for one address and can be accepted only by somebody signed in as that address.
- 3
They accept
Following the link lets them create a password — or sign in, if they already have an account — and joins them to the workspace. Whoever sent the invitation is told when it is taken up.
- 4
Chase it, or withdraw it
An invitation lasts seven days. Resend issues a fresh link with a fresh week on it; Revoke withdraws it. An expired invitation cannot be accepted — the person is told to ask for a new one.
| The table shows | Meaning |
|---|---|
| Pending | Sent and not yet accepted. These are the ones to chase. |
| Accepted | Taken up. The person is now on the account. |
| Expired | Seven days passed. Resend or drop it. |
| Seats open | What your plan leaves. Agent invitations consume a seat; sub-agency invitations do not. |
Changing a role later
- A member's role can be changed, and removing a member ends their access immediately. Both are written to the activity log.
- Ownership moves by promotion. The owner seat cannot be demoted directly — promote somebody else to owner and the previous owner becomes an admin in the same movement. A workspace can never be left with no owner, and never with two.
- Only the sitting owner, or our staff acting on the account, may change who the owner is. An admin can do everything else.
- The owner cannot be removed either. Transfer ownership first, then remove the seat. It is the same rule from the other side: there is no sequence of steps that leaves a workspace ownerless.
- Promote to admin rather than sharing the owner's login. They are the same access for daily work, and only one of them is attributable.
A membership also carries a status. active is the normal one; locked and suspended stop somebody acting without removing the record of what they did, which is the right tool for a colleague who is on leave or under review. Removal destroys the membership; their entries in the activity log stay, because the log is not theirs to take away.
Administering more than one workspace
Owner and admin authority flows down the account tree, so a parent's admin administers every workspace below it without holding a seat on each. That raises a question the platform refuses to guess at: which workspace is this request for?
- Hold a seat on exactly one workspace and it is assumed. Nothing to choose, nothing to send.
- Hold seats on several and the request must name one —
?agencyId=on the API, and the workspace switcher in the console. The thing you are about to create is a number or a buyer somebody is billed for, and picking a workspace on your behalf is how it lands on the wrong bill. - Hold none, and the console refuses: call tracking is administered by a workspace owner or admin.
- An API key never has this problem. A key belongs to exactly one workspace and acts as it, which is another reason not to share one between businesses.
People, publishers and keys are three different things
| A team member | A publisher's login | An API key | |
|---|---|---|---|
| Is | A colleague. | Somebody at a company that sends you calls. | A program. |
| Signs in to | Your console. | The publisher portal, which shows their side only. | Nothing. It calls the REST API. |
| Holds | A role: owner, admin or agent. | A seat on that publisher, invited by you or by them. | Scopes. |
| Can see your buyers and margin | Yes. | Never. | Yes, within its scopes. |
| Appears in the activity log as | user | publisher_member | api_key, named by its label |
staff in your log when they act on your account, not only in ours.Inviting a publisher's contact is done from that publisher, not from Team. It gives them nothing inside your workspace — see Publishers overview.
Worked example: bringing on a media buyer
You have hired somebody to run campaigns and buy traffic. They need to change routing plans and read every report, and they should not be able to change the plan or move money.
- Check Seats open first. If the plan is full, the invitation cannot be sent and you will want to sort that out before promising a start date.
- Invite them as an agent, to their work address — not a shared inbox, for the reason below.
- Once they have accepted, set their role to admin so they can administer the workspace. Admin is the working role; agent is a seat on the wider account and does not open this console.
- Do not give them the owner seat. Admin covers campaigns, buyers, targets, publishers, numbers, webhooks and keys; the owner keeps the plan and the wallet.
- If they also need programmatic access, issue them their own API key named after what it does, rather than sharing an existing one.
- A fortnight later, read the activity log filtered to them. It is the fastest review you will ever do, and it is only possible because they signed in as themselves.
What a team member can reach
An owner or admin can do everything in the tracking console. A few things are worth knowing about before somebody discovers them.
| They can | Consequence worth knowing |
|---|---|
| Set a campaign live, or pause it | A live campaign means strangers' calls start reaching somebody's phone. Pausing stops that on the next call. |
| Change a routing plan | It takes effect on the next call. Calls already in progress keep the plan they were routed on. |
| Change a buyer's price or caps | Only for calls that arrive afterwards. A call's terms are frozen when it arrives — see Conversions and adjustments. |
| Correct a call's books | Your reports change, including reports covering past dates. Nothing moves a wallet. |
| Export the call log | A file of your callers' numbers leaves the platform, and the activity log records it at high severity. |
| Create and revoke API keys and webhooks | A key is a credential with your workspace's authority. Name it after what uses it. |
One person, one login
- The same applies to programs. A key shared between two jobs means revoking it breaks both, which is how a leaked key stays live for a fortnight.
- Remove people when they leave, the same day. Removal ends access immediately and is itself an entry in the log.
- Rotate anything a departing colleague knew: keys they used, and webhook signing secrets they had copied.