Skip to main content
A master agent is one agent and one campaign that run across many sub accounts at once. The builder calls this a master agent. It shares a campaign across projects; the ordinary Campaigns guides still explain its script, triggers and workflows. You build it once. Every project you link to it gets its own working copy. When you edit the parent, the change reaches all of them.
This is the tool for running the same offer across many locations: a franchise with forty branches, an agency running one proven campaign for thirty clients. If you only have one sub account, you want a normal campaign.

​
The one idea that makes it work

Every linked project has a real campaign of its own. A master agent is not a template you copy once and then maintain in forty places. The children stay connected to the parent for as long as they are linked. That leaves one question, and it is the whole design:
1

Some things must be identical everywhere

The script, the call flow, the tag names, the retry cadence, what happens after the call. If these differed per project, you would not have one campaign, you would have forty.
2

Some things cannot possibly be identical

The calendar it books onto. The pipeline stage it moves people to. The number it transfers to. Every sub account owns its own, and they are different records with different IDs.
The first kind syncs from the parent. The second kind is set per project. The system calls the second kind bindings, and getting them connected is the only real work of setting a master agent up. See what syncs and what stays local for the full split, and connecting a project’s own assets for how bindings get filled in.

​
What you actually do

1

Build the parent like any other campaign

Script, audience, calling window, post-call actions. Nothing special.
2

Link the projects

Each one gets a child campaign, and the system tries to connect that project’s own calendar and pipeline automatically by name.
3

Fix whatever it could not match

Anything it could not connect confidently is reported rather than guessed. A child cannot go live until its bindings are sorted.
4

From then on, edit the parent

Every save fans out to the children in the background.

​
Where it lives

Linking projects to a master agent happens in the Settings tab, and the setup state for each linked project is shown in Project Manager.

​
The failure this design prevents

If a local calendar ID were allowed to sync from the parent, every linked project would start booking into one sub account’s calendar. Forty clients’ appointments landing in one calendar, silently, and looking fine until someone checks. Three clients each book one appointment. If the calendar were copied from the master, all three bookings would land in Oak's calendar, the sub-account the master lives in, and Peak and Bay would get none. Because each keeps its own, every client gets its own booking. Three clients each book one appointment. If the calendar were copied from the master, all three bookings would land in Oak's calendar, the sub-account the master lives in, and Peak and Bay would get none. Because each keeps its own, every client gets its own booking. That is why bindings are never inherited, and why a project with an unresolved binding is blocked from going live rather than allowed to run and be wrong.

​
In the API