Repairing the silent automations behind a deal-flow dashboard

The problem

Funnel and speed metrics are computed from the dates deals moved between stages. Here, those dates were being stamped by a webhook (a real-time trigger: the CRM calls your program the instant something changes) that had quietly stopped running. A separate automation inside the CRM, which maintained calculated display fields, had stopped months earlier.

Neither failure produced an error anyone saw. Deals with missing dates did not show up as wrong; they simply vanished from the funnel chart. The report was not so much incorrect as quietly incomplete, which is worse, because incomplete looks fine.

What we found

The discovery pattern is worth stealing. Sort the records by creation date and look for where a field stops existing: every record created before a certain date has the field, and every record created after does not. That boundary is the automation's date of death, readable straight out of the data months later. Applied here, the pattern exposed two separate dead automations that had failed months apart, neither of which had ever announced itself.

What we built

The backfill. The CRM's own status history still recorded when each deal had moved between stages, so the missing values were recoverable. We reconstructed and backfilled 76 date fields across 54 deals from that history. The backfill wrote only where a field was empty, never over a value a human had set, so it could not damage anything by being wrong.

Stamping moved to a scheduled job. A webhook fires once per event, and when it dies, every event after that is simply lost. The date-stamping was moved into a scheduled job that re-checks the whole book on every run and repairs any drift it finds, so a missed event is corrected on the next pass instead of lost forever.

The sync job made reliable. The daily job maintaining per-company data made one API call per company, across roughly 3,600 companies. It ran about 19 minutes against a 20-minute limit, and on slow days a single transient server error killed the whole run. Fetching the data in bulk up front and wrapping every call in automatic retries brought the same job down to about a minute. An enforcement job must itself be reliable, or it becomes one more silent failure.

A dashboard that rebuilds itself. The deal-flow dashboard now regenerates from the live CRM every weekday morning, so the numbers a partner reads on Monday are Monday's numbers, with no human in the refresh path.

What happened

The revealing moment came after launch, when a partner pushed back on the funnel chart. The first version showed each deal at its current stage, a snapshot of right now. That silently dropped every deal that had already been killed, so the pipeline looked thinner than the year really was.

What the partner wanted was the cumulative funnel: every deal counted at every stage it ever reached, including the deals that later died. Those are two different questions. One asks "what is in flight right now?" and the other asks "how well does our top of funnel convert?" No amount of extra metrics would have surfaced that difference. It surfaced because the page was shaped around one person's real question, so that person could see it was answering the wrong one. The correction shipped, and the cumulative funnel is now the chart the firm reads.

Outcome

The dates the funnel needs are populated and stay populated, because the job that maintains them re-checks everything on every run. The dashboard rebuilds itself every weekday morning. And the automations behind the reports now live somewhere visible, in version control, with logs and retries, instead of inside the CRM where nothing tells you they have died.

The general lesson from this engagement: if a report your fund relies on depends on an automation, that automation needs to live where you can see it running. One-shot fixes decay silently; enforcement on a schedule is what keeps a repaired system repaired.