Review a batch of campaign changes

One connection, up to fifty operations, reviewed and approved as a single unit. A longer list is refused rather than truncated, which matters because a silently shortened batch is a change set that does not match what anybody asked for.

Where entries depend on each other — a campaign, the group inside it, the ad inside that — each child names the index of the entry that creates its parent, so nothing carries an identifier that does not exist yet. That is what lets a three-level structure arrive as one reviewable thing rather than as three rounds of approval.

A batch belongs to one connection. Work spanning two connections is two batches by construction, because two connections can never be applied together. A media plan whose items land on two connections materialises into two batches, each keeping its items in board order.

Nothing stores a batch status. The rollup you read is computed from the rows, which is why it cannot drift from them.

The authority. It says pending when the batch is waiting for a person, and it names the rule when a rule your workspace wrote cleared every row of it on the way in. Those are the two authorities there are. If it names a rule you did not expect, stop and read the rule before anything else.

The row count against what you asked for. A batch with more rows than the instruction implied is the most useful early signal there is. Fifteen rows for "adjust the two worst performers" is a conversation, not an approval.

The warnings. Each row carries any warnings it collected, each with a message saying what the condition means for the answer it travels with and a link to the record it is about. The classes worth slowing down for are the budget ones — an amount near the account's daily cap, a large move from the current amount, increases on this connection already adding up over the last day, or a budget shared across several campaigns so that changing it changes all of them — and the currency ones, particularly a scope whose rows are in different currencies.

A warning never changes a value and never refuses anything. It says what is near, which is exactly what a reviewer wants.

Three things per row, and they are quick.

The operation and the level. What kind of change, on what. A create is different in kind from an update: creates land paused, so approving them builds structure without starting delivery.

The amount and its currency. Money is an integer in minor units with the account's currency stamped on it by the server rather than supplied by whatever asked for the change. If the currency is not what you expected, that is the finding.

What it is changing from. Every row records the state it would change from. This is the field that makes a review possible at all — without a pre-image you are approving a destination with no idea of the distance.

If a platform offers a dry run, its verdict is already on the row: Tempio asks while the change request is being written, so a platform's objection arrives here with the platform's own message and the fields it names rather than after approval.

Approve. Takes the batch, or a list of rows, and moves them whole or not at all. The rows are claimed at approval. Approving the same batch again picks up the rows not yet cleared rather than starting over, so an interrupted approval is resumable.

Reject. Terminal. A rejected row can never be cleared, by you or by a rule. Use it when the change is wrong in kind rather than wrong in detail.

Replace the payload. The one most people miss. A row that needs a different number does not have to be rejected and re-drafted: replacing its payload re-validates it, re-stamps the currency from the target account, re-runs the guardrails, and a row whose apply had failed goes back to waiting.

The arrangement all three sit 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.

The batch stops at that row. Rows behind it were claimed and do not run, which is deliberate: continuing past a failure is how a change set half-lands in an order nobody chose.

A row that half-landed stops the batch the same way. Some platforms build one logical change out of two calls, and a first call that succeeded with a second that did not is a state the batch refuses to build on.

The batch is resumable. Edit the failed row's payload with whatever the platform asked for and it goes back to waiting, and approving again picks up from there. Nothing has to be re-drafted from scratch, and the record keeps the whole sequence rather than replacing it.

Worth knowing at the gate, because it explains why some batches arrive for a person even in a workspace with rules.

No rule clears a create of any kind, a media upload, a removal, a change to account defaults, or a raw platform request. None clears an increase, an amount over its own cap, or an amount in another currency. None clears a change whose direction cannot be read — no pre-image, or a budget that switched between daily and lifetime. None clears a draft the platform's dry run refused, or one carrying a special ad category. And none clears anything on a connection whose kill switch is on.

A batch is one unit, so one row a rule cannot approve sends the whole group to you. That is why a mixed batch is a person's even when most of it would have cleared.

Undo is a new draft built from the state the entity was in before the change, going to the same gate with the same guardrails. There is no separate rollback path, and a removal has no undo at all — which is why a removal says so in a sentence before it is approved.

Where the batch is the structure for something about to start, the launch checklist template is what to read beside it: approving a batch of creates builds everything and starts nothing, so the checklist is the list of things that have to be true before the second change is drafted.

What happened is on the record: Who approved what, and when. If the reason you are reading a batch is that a week went wrong, Audit an ad account after a bad week is the wider procedure, and Guardrails that stop expensive mistakes explains the limits the rows have already passed.

The habit underneath this procedure, borrowed from code review, is Reading a change request like a diff.