Timeline

The timeline is one calendar over everything the workspace is running and everything it intends to run. It lives at /timeline, behind the Planner entry in the sidebar, and it answers the question a media buyer actually asks: what is running, what is about to, and is any of it off plan.

A plan is a lens over the same calendar rather than a chart of its own — the Plan tab at /plans/<plan> draws this timeline filtered to that plan's items and the campaigns they became.

The toolbar

Two rows sit over the calendar. The first holds the view picker (Timeline, List or Board, each as a link, so a link reproduces the view), View settings, Plans and New plan. The second holds the zoom, Today, one dashed Filter chip and the count of flights. The filter opens a menu with Channel and, from two accounts up, Account; once a dimension is set it is a chip of its own ("Channel is Meta or Google") with a button that clears just that one. On a phone the list is the only view, and the picker, the zoom and Today are not drawn.

How it is laid out

Rows are grouped by ad account, and the Name column down the left is 250 pixels wide. Each account's head row carries the platform's tile, the account name, the currency it bills in, the daily cap its guardrails resolve, and what the account spent on its own yesterday as a thin meter against that cap. Spend that has not synced for that day reads as unknown rather than as zero. Under the head, each lane has a chip in the Name column, the lane's tile and its name, and a press on the chip opens the same peek as a press on the bar.

Under each account:

Phases render as bands beneath the bar, labelled by kind with their multiplier, and the phase covering today is emphasised. The today line is the workspace's reporting day. Archived and deleted campaigns are not drawn; paused ones are drawn at reduced emphasis.

On a plan's page, an item on a platform with no connected account sits in a group of its own, named for the platform and "not connected", with no cap meter. It opens, moves and saves like any other item, so a plan can be built before its channels are connected.

Below tablet width the chart yields to the list — name, account, status, flight, pace and budget, one row for each lane — the way the items table stands in for the plan chart. Its names and flights draw first, and the figures follow when they are read.

The window is a viewport

The window you are looking at is what is drawn, not what is measured. A campaign whose flight began two months before the window still paces against its whole flight; scrolling or zooming changes the picture and never the arithmetic. Zoom has six levels: Days, Weeks, Months, Quarters, Half-year and Years. Pick one from the list or step with − and +. It moves the width of a day column, from 40 pixels to one, and keeps the day in the middle of the view where it was. The window, the zoom, the channel chips and the account picker are all in the URL, so a link reproduces exactly the view you were looking at.

What each state means

The fill inside a bar is spend to date over planned to date — see Pacing for how both halves are computed. The state is carried by colour and by a word, always: the word is on the bar where there is room, beside a bar too short to hold its own name, and in the bar's tooltip and accessible label, so a reader who sees no colour at all still reads the state. A bar with room for its name and none for the word shows a dot in the state's colour before the name, and a bar too short for its name shows the dot with the name beside it.

Not measured draws no fill rather than an empty one, because an empty bar and an unmeasured bar are different facts and only one of them is news. The same rule holds for a campaign whose metrics have not synced: the bar renders with no fill and says so.

Colouring a bar

Right-click a bar and pick one of fifteen colours, or No colour to clear it. The same swatches are in the peek a bar opens. The colour saves as you pick it and belongs to the workspace, so everyone sees that bar in that colour on the timeline, on its card on the board and on its row in the list. A colour is planning metadata, so nothing is sent to the platform and no change request is written. View settings in the toolbar has Colour by, which paints every bar by platform, status or pace for you alone. That choice is kept in the link as colour, and the colours people picked stay as they were.

Key dates

View settings in the toolbar has Show key dates. Turn it on and the timeline marks the periods a plan is made round. A run of days, such as Black Friday to Cyber Monday, is a tinted band down the calendar, and a single day, such as Halloween, is a dashed line. Both sit behind the bars, so a bar over one is dragged, resized and linked as it is anywhere else. The names sit in a strip under the header. Two names that would meet stack on a second line, and at the wide zooms the ones with no room fold into a chip that counts them, such as +3. Point at a chip, or tab to it, for the name and its days.

The dates are worked out from rules for whatever year is on screen, so Black Friday is right in 2031 without anybody updating it. Region in the same menu picks whose calendar is drawn. Tempio starts from where your ad accounts are (their time zones, then their currencies), then your browser's region, then the United States.

Amazon Prime Day and Click Frenzy are not on the list, because their dates are announced each year. Add them yourself once they are.

Manage key dates… in the same menu opens the workspace's own dates, over a read-only list of the built-in ones for your region. Add one with a name, the day it starts, the day it ends if it runs longer than a day, and a colour if you want its band to stand out. Turn on Repeats every year and it comes back on the same month and day, the same number of days long; a date on 29 February falls on the 28th in a year without one. A date you add shows on the calendar as you save it, and everyone in the workspace sees it when they have key dates on. Like a bar's colour it is planning metadata: nothing is sent to a platform and no change request is written.

The switch and the region are kept in the link as keydates=1 and region, so a link you share opens on the same calendar. The list and the board do not draw key dates.

Moving a flight

Dragging a live campaign's bar along the calendar does not move the campaign. The bar lifts and follows the pointer, the header marks the days it would land on a day at a time, and on drop a dialog asks:

Move this flight? Nothing moves yet. This writes one change request; the flight the platform is running stays where it is until the gate clears it.

The dialog states the flight now, the flight after, and what the move implies at today's daily budget. Draft the change writes one update_schedule change request; Leave it where it is closes it and nothing is written. Dragging an edge rather than the whole bar moves one boundary the same way.

Until that draft applies, the bar keeps the dates the platform is actually running and the drafted flight is drawn as a dotted outline beside it, linked to the draft. If the draft is rejected the outline goes and the bar was never wrong. If the flight has already begun the dialog says so, because some platforms refuse a new start date on a running campaign — and if one does, the refusal comes back from the gate and nothing is applied.

A plan item moves immediately. A plan is a working document and nothing in it touches live spend, so a dragged item is saved and audited like any other plan edit, with the item form's validation applying: the new flight has to sit inside the plan's window. Once the plan is materialized its items are frozen: their bars have no handles and do not drag, and their peek shows the item with a link to the draft it became.

A bar with no flight dates does not lift either. It is drawn as a marker at today, a click opens it, and its tooltip says why it does not move. Set its dates in its peek and it drags like any other.

Milestones

A milestone is a date the flights are planned around: creative sign-off, a launch, the day a report is due. Add one from a plan's page. The new item's form has a Flight and Milestone choice at the top, and Milestone leaves one date field and takes the budget and the end date away.

On the calendar a milestone is a diamond in the middle of its day, with its name beside it, its date under the name and a thin line down the calendar. It drags along the calendar and onto another row like a bar, takes a colour from the same menu, and has no ends to resize. From the keyboard the arrow keys move it a day, or a week with Shift. In the list and on the board it shows the diamond and its one date.

A milestone has no budget, so it is left out of everything that adds a plan up: the plan's total and its count of items, the totals by platform and by month, pacing, and the board's column sums. Materializing a plan drafts its flights and never a milestone.

Dependencies

A dependency says one lane starts after another ends. Either end can be a live campaign, a planned flight or a milestone, in any account.

Put the pointer on a bar and two dots appear beside it. Drag from the one at the bar's end to a bar that comes after it, or from the one at its start to a bar that comes before it. A line follows the pointer, the bar it can land on lights up, and letting go there makes the link. Letting go over empty calendar, or pressing Esc, makes nothing. From the keyboard, open a bar's menu and choose Link to what comes before… or Link to what comes after…, then pick the other lane from the list, which you can search.

The link is drawn as an arrow from the end of the lane that goes first to the start of the lane that waits on it. The arrow is grey while the dates agree and red while the second lane starts before the first one ends. An arrow that crosses another row passes behind the bar on it.

A link moves no dates. Move a flight and the lanes that wait on it stay where they are. If that leaves them overlapping, the arrow turns red and the dates are yours to change. A dependency is planning metadata: nothing is sent to a platform, no change request is written, and each link made or removed goes into the audit log.

To remove a link, put the pointer on its arrow and press the button that replaces the arrowhead. The button also takes the keyboard's focus, where Delete or Backspace removes the link. A toast names what was unlinked and offers Undo. The peek a bar opens lists what the lane waits on and what waits on it, each with a remove button.

Tempio refuses a link that would make a loop, and the refusal names every lane in it. It also refuses a second link between the same two lanes in the same direction.

Placing a row

Drag a bar up or down and it changes row. The rows of its account slide apart as the pointer crosses the middle of each one, a line marks the boundary the bar would land on, and it stays on the row you drop it on. The order is the workspace's, so everyone sees the account's rows in it, and it is kept across reloads. A toast names the move and offers Undo. A lane nobody has placed sorts after the placed ones, by start date.

A drag is about one thing. If the pointer has gone further up or down than across by the time it is eight pixels from where it went down, the bar's dates are held for the rest of the drag, and the header shows them unchanged. Otherwise it is a date move, and the row changes too only if you let go over another row.

A plan item dragged into another account on its platform lands at the line in that account, changes account and keeps its dates. A live campaign is placed among the rows of its own account. A row order touches nothing on a platform and waits at no gate: it saves on the drop and is written to the audit log.

From the keyboard

Every bar is a focus stop, and the keyboard does the same three things the pointer does.

A nudge is announced as you make it — the name, the flight it would run, and that enter drafts it. Moving focus off the bar drops the nudge rather than leaving a move nobody can see waiting to be committed.

A worked example

An account bills in AUD. Spring Sale runs 1–31 March at A$120.00 a day and is nine days in, with A$864.00 spent.

• Planned to date, 1–9 March, is nine days at A$120.00: A$1,080.00.
• Spend to date is A$864.00, so pace is 0.8 — below nine tenths.
• The bar fills to 80 % and reads Behind, with "A$864.00 against A$1,080.00 planned (0.80×) — behind the plan."

Dragging the bar three days later opens the dialog: Now 1–31 March, After 4 March – 3 April, and at today's budget the implied flight total. Drafting it writes one change request. The bar still says 1–31 March, with a dotted outline over 4 March – 3 April, until somebody — or a rule the workspace wrote — clears it at the gate.

Clicking a bar

A campaign's bar opens its peek, a side panel with its flight, today's budget, its envelope and phases, its goals, its pacing sparkline, the drafts open against it, and a link to the campaign. Owners and admins can set the envelope there; everyone can read it. A planned flight's bar opens the plan item's own peek, and a new item opens as a form dialog.

Over MCP

The same calendar is one read.

get_timeline takes a window, channel and account filters and a plan id for the lens, and answers accounts → lanes: the flight, what each lane is running at per day, its phases and multipliers, its envelope, its goals with their verdicts, how it is pacing, and the drafted flight still waiting at the gate as pendingFlight. It defaults to today and the next sixty days in the workspace's reporting zone. The same payload for that default window is also readable as a workspace resource, so a client can attach the calendar to a conversation without making a tool call. The MCP reference lists both.

planner_colour_set gives one or many lanes a colour by name, or clears it with colour: null, and every lane get_timeline returns carries its colour. It writes no change request.

planner_order_set places one lane directly before or after another in the same account. get_timeline returns each account's lanes in that order, with each lane's position. It writes no change request either.

plan_dependency_add links a predecessor to a successor, each named as { kind, id } with kind either campaign or plan_item. plan_dependency_remove takes the link away by its dependencyId, or by the same two lanes. get_timeline returns dependencies, every link whose two ends are both lanes of that read, and each plan item lane carries itemKind, flight or milestone. Neither tool writes a change request and neither moves a flight.

upsert_plan_item takes kind. A milestone needs startDate alone; leave endDate and budget out.

planner_key_dates_list returns the key dates in a window: the built-in ones for a region and the workspace's own, earliest first, each with its name, startDate, endDate and a source of built_in or custom. Leave region out and it is read from the workspace's ad accounts; leave the window out and it runs a year from today. An agent planning a quarter reads it first, so a launch does not land on a peak by accident. planner_key_date_upsert adds one of the workspace's own dates, or edits the one id names, and planner_key_date_remove deletes one. Neither writes a change request and neither moves a flight.

Moving a flight from an agent is not a timeline call: it is draft_changes with an update_schedule, the same change request the drag writes.