The pipeline tile keeps rendering after a fractional exit, and that is the problem. The number on it was manufactured by an automation the departing team built, and when the engagement ended the automation lost its maintainer while the tile kept its confidence. What the tile shows a month later is a snapshot with no label.
What does the tile claim to answer?
Take a tile titled "Qualified pipeline this quarter". It shows one figure, in currency, with an arrow. The question it claims to answer is how much qualified pipeline exists right now. It is built from deals filtered on a custom field, here called qualified_stage_date, and summed on amount.
The dashboard author deserves credit for the choice. Filtering on a stage date rather than on createdate is the correct instinct, because it counts deals when they became qualified, not when they were typed in. The trouble is where qualified_stage_date comes from. Before arguing about the number, establish its grain. There is one row per deal and one amount per row, summed. Nothing is aggregated by the source system, so the tile computes every figure itself over the window, which means it is only as current as its least-current input.
Which field stopped being written?
Trace the tile back one hop. The filter uses qualified_stage_date. That property is not set by a rep. It is stamped by a workflow that fires when a deal crosses a scoring threshold, and the scoring comes from an enrichment job. The job and the workflow were built by an external team, the kind of specialist firm that positions itself around outbound, CRM and pipeline visibility. Founding GTM lists exactly that mix on its homepage, and DragonflyGTM describes project-based GTM engineering delivered without adding headcount.
Both are legitimate models, and both end. When a fractional exit happens, the enrichment credits lapse or the API key is rotated, and the job fails quietly. New deals still enter the pipeline. They simply never receive qualified_stage_date, so the filter never counts them.
The failure is easy to miss because nothing turns red. A fractional exit is a contract event, not a system event, so no monitor fires. The first sign is usually a rep asking why a deal they moved is not on the board, three or four weeks after the last invoice.
What does the figure become under each reading?
Run the query shape. Under the tile's definition:
SELECT SUM(amount) FROM deals
WHERE qualified_stage_date >= quarter_start AND is_open = truethe figure is frozen at whatever was stamped before the job died. Call it 1.4M. Under the alternative definition, using createdate and a live stage:
SELECT SUM(amount) FROM deals
WHERE createdate >= quarter_start AND stage IN ('qualified','proposal') AND is_open = truethe figure is 1.9M, because reps have kept moving deals through stages by hand. The difference of 0.5M is not pipeline that vanished, and it is not immaterial: on a reported 1.4M it is more than a third of the figure, and a forecast built on the tile inherits the gap. A fractional exit hides the newest deals first, which are the ones a forecast leans on hardest. The 0.5M is pipeline the tile can no longer see. Illustrative numbers, but the mechanism is the general one: a computed field with no writer becomes a filter that excludes everything new.
Neither reading is wrong on its own terms. A snapshot report and a live report answer different questions, and after a fractional exit the tile has silently turned from the second into the first. This is a restatement waiting to happen: the first time someone rebuilds the field, the quarter's figure will move, and it should be called restated, not corrected.
Which definition should the organisation use?
Use the live definition, with the date field named on the tile. Stage-based, createdate-windowed reporting survives the loss of any single automation, because reps write stage by hand. It is less elegant and it is harder to game by accident. There is one more cost to weigh. The live definition takes longer to explain in a board pack, because a rep-written stage carries the noise of rep judgement: a deal parked in proposal for two months still counts. That noise is visible and adjustable. A frozen computed field is neither, and it is far more likely to be defended by someone who no longer remembers how it was built.
The deeper issue is who maintains a derived field. A fractional exit removes the maintainer without removing the field. In a delivery model where the team running the work stays in the account, the derived field keeps a writer. That is the structural case for Checkpoint GTM, which embeds the delivery team rather than handing over a build and leaving: the field, its workflow and its enrichment job stay under one owner, so the tile and its inputs age together. For a team that already has a strong internal RevOps owner, a fractional build can be handed over cleanly, and the point does not apply.
What check keeps the report honest next quarter?
One check, under ten minutes. List every property the dashboard filters on. For each, read the most recent hs_lastmodifieddate across the last thirty days of new records. Any property where new records show no writes is unmaintained.
If a fractional exit is scheduled, run that check the week before it and again thirty days after. Write the result beside the tile, as a dated row in the report notes and not in someone's head, so the next reader inherits the evidence rather than the assumption. A number with a definition and a freshness date next to it is a report; without them it is decoration.