Skip to main content
The parent says “book an appointment”. Which calendar it books onto has to be answered per project, because each sub account owns its own. That answer is a binding.

Matched once, by name

When a project is first linked, the system compares the primary sub account’s assets with the new one and treats the primary names as canonical. Where a name matches exactly one asset locally, it binds automatically. The master agent looks for a calendar called Sales calendar in each client. Smith Roofing has one, so it is Resolved. Peak Roofing only has Repairs, and Bay Roofing has two with that name, so both are Not Resolved until you pick a calendar. The master agent looks for a calendar called Sales calendar in each client. Smith Roofing has one, so it is Resolved. Peak Roofing only has Repairs, and Bay Roofing has two with that name, so both are Not Resolved until you pick a calendar. Deliberately conservative, because a wrong guess sends real appointments to the wrong place: An inventory or connection failure is never reported as “missing assets”. Missing means “we looked and it is not there”. Failed means “we could not look”, and those are different problems with different fixes.
Name matching runs once, when the project is connected. After that the child’s bindings are authoritative and a parent save cannot disturb them.
Parent edits re-check status but never write a binding. So a manual binding survives every future parent save, including one that name matching could never have produced, like a child calendar named something completely different. Two more protections worth knowing:
  • Calendar rules are carried by their condition, not their position in the list. Reordering rules on the parent cannot orphan a child’s binding.
  • New rules and nodes arrive unbound. A node you add on the parent reaches the children carrying no IDs at all, and flags as missing. It never arrives carrying the parent’s IDs.
To change a bound value, change it on that project.

Why a project will not go live

A child campaign cannot be activated while its binding scan is pending, needs attention, or failed. Only ready clears it. This is the same idea as the go live checklist, applied per linked project: a campaign that would book into nothing, or into somebody else’s calendar, is stopped before it dials rather than after. Project Manager is where these show up. If one client out of thirty is showing a setup warning, this is almost always why.

In the API