Turn a media plan into campaign drafts

Three things worth checking while the plan is still free to edit, because after this step none of them can be fixed in place.

Every item resolves to an account. An item with an account named on it uses that one. An item with none resolves if the workspace has exactly one account on that item's platform. Zero accounts, several, or an account that has since gone, and the item is unresolved.

Every account bills in the plan's currency. A plan carries one currency and every budget in it is in that currency's minor units. An item pointed at an account billing in something else is refused by name rather than converted, because money never silently crosses currencies on the writing side.

The derived daily figure is sane. Each item's budget is the whole-flight total, and the daily figure is the total divided by the inclusive length of the flight. That derived number is what meets the guardrails, so it is the number to check — a short flight carrying a large total produces a large daily rate, which is the most common reason a plan refuses.

Names are worth a last look too. The item's name is carried straight onto the draft and then onto the campaign, so it is the name a report groups on six weeks from now.

It is validate-everything-then-write, and the order is the guarantee.

It re-reads the plan and its items. Not the rows it was shown a minute ago. A concurrent edit narrowing the window must not sneak an out-of-window flight into a draft.

It checks each item. The flight sits inside the plan's window, the budget is a whole number of minor units at or above zero, and the dates run forwards.

It resolves an ad account for every item. Every unresolved item is collected and named in one message, so you fix them together rather than one refusal at a time.

It checks each account's currency against the plan's, naming the account and what it bills in when they disagree.

It runs the guardrails. The connection's kill switch and the account's budget guardrails, using the same functions the gate itself runs, so the pre-flight and the gate cannot disagree. Running them here as well as at the gate is what makes "fails whole" true across batches: a refusal on the last item must not leave the first connection's batch sitting in the queue.

Then it writes the drafts. One create-campaign change request per item, in board order.

A failure at any of those steps drafts nothing at all.

One batch per connection, with the items keeping their board order inside each batch. A batch is the review unit and the apply unit, and two connections can never be applied together, so a plan whose items land on two connections becomes two batches with two links to the gate.

Each item's whole-flight budget becomes a daily budget on the draft — the total divided by the inclusive length of the flight. The flight days become instants in the ad account's own timezone, with the stop exclusive. The plan's currency is stated on the payload, and the gate re-stamps it from the account regardless, so the draft cannot end up denominated in something the account does not bill in.

Two properties of what comes out are the reason this step is safe to use.

A create is one of the operations no approval rule may ever clear, so a materialised plan always waits for a person. That is not a general claim about every change — a rule you wrote can clear other things on the way in — it is a property of creating something that did not exist.

And every create lands paused on the platform. Approving the batch builds the structure and spends nothing; starting delivery is a second change through the same gate. Two acts, two records, rather than one act with a side effect — which is exactly what a phased plan wants.

Stated once in full: 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.

An item flying outside the plan's window. Names the item and both windows. Move the item, or set a plan window that covers it. The check runs in both directions, so this also appears when a window was narrowed under an item that no longer fits.

An unresolved ad account. Names every unresolved item at once. Set an account on each, or connect a channel with exactly one account on that platform so it resolves on its own.

A currency mismatch. Names the account and what it bills in. Point the item at an account in the plan's currency, or plan that window in the account's currency. There is no third option, because nothing converts here.

A guardrail refusal. Names the number. Almost always the derived daily figure sits above the account's own ceiling, which is three times the highest single-campaign daily spend in its last twenty-eight days, floored at a default in the account's own currency. The flight is shorter than the budget assumed, or the budget is larger than the account's history supports. Lengthen the flight, lower the total, or split the line into several campaigns.

A fifth possibility is not a refusal but a stop: a connection whose kill switch is on blocks everything written against it, whatever is queued and whatever rule would otherwise have cleared it.

The plan freezes. Name, brief, window, currency and items all stop being editable, because the plan has become the record of what was drafted and editing behind that record would make the record untrue. Archive is the only thing still allowed, and it is how a plan is retired.

The page changes with it: while the plan is a draft it offers the materialise action, and once it is materialised it points at the drafts, where the decisions now are.

Re-planning the same window means archiving and starting a new plan. That is more honest than an editable history and costs about five minutes, because the numbers you are re-planning from are in the account rather than in the document.

The batches are at the gate. Approving takes either the batch identifier or a list of individual rows and moves them whole or not at all; the rows are claimed at approval, and approving the same batch again picks up the rows not yet cleared rather than starting over. Rejecting is terminal — a rejected row can never be cleared, by you or by a rule.

A row that needs a change does not have to be rejected and re-drafted. Replacing its payload re-validates it, re-stamps the currency from the target account and re-runs the guardrails, and a row that failed its checks goes back to waiting.

How to write a media plan is the document this step consumes, and Why every change is a draft is the reasoning behind the gate it feeds.