Automatic Lead Capture and Pipeline Handoff Automation: Fixing a Chain That Had Never Once Fired

A marketing automation feature can look completely finished from the settings screen — a trigger selected, an email drafted, a wait period configured — and still never fire a single time, if any one link in the chain between "someone submits a form" and "the automation engine receives that event" is broken. The settings screen has no way to show that gap; the only way to find it is to trace what actually happens to a real submission, end to end, through every intake path.

A chain with several independent links — intake creates a record, a trigger notices it, a dispatcher calls an engine, a worker routes the event, an executor runs the step — has exactly as many places to quietly break as it has links, and each individual piece can look correct in isolation while the chain as a whole never completes. A slug that no longer exists, an argument name that changed on one side but not the other, a missing foreign key that a later step assumes exists — none of these throw an error a person would see on a settings page; they just mean nothing happens, forever, until someone traces one real event through every step by hand.

The starting diagnosis, recorded directly in the fixing migration's own header, named four separate defects rather than one vague "automation doesn't work" ticket: the widget intake wrote a form submission row without ever populating its contact reference, while dispatch logic requires that reference to exist; no intake path called the automation engine at all — the deployed handler for one intake route referenced a function slug that had since been retired, and the resulting error was silently swallowed rather than surfaced; the deployed worker's own event-routing map pointed a dispatch event type at a second slug that likewise no longer existed; and the executor accepted one argument name while the dispatcher was sending a different one. All four were confirmed and fixed in the same release — this page describes the two fixes that live in the database as triggers, verifiable directly against the migration rather than against a deployed function's current state.

The first trigger runs BEFORE a form submission row is even inserted: if the incoming data includes a validly-shaped email and the submission doesn't already carry a contact reference, it looks for an existing Flow contact with that email under the same account and reuses it (updating a last-seen timestamp), or creates a new one from whatever name, phone, and company fields came in in the submission itself. This has to happen before insert specifically so that everything downstream — the dispatch trigger, the Orbit bridge — sees a populated contact reference on the very first read of the row, not on a delayed follow-up.

The second trigger runs AFTER that insert and dispatches any matching nurture sequence — but only after checking that the account actually has an ACTIVE automation configured for a "form submitted" trigger; if none exists, the trigger exits without spending a network call. When one does exist, the dispatch is a fire-and-forget HTTP call to the automation engine, authenticated with a service-role credential pulled from the platform's own secret vault rather than a value baked into the trigger itself — the same pattern the platform's scheduled jobs already use.

A third mechanism, the Flow-to-Orbit bridge, turns a qualifying submission into a real sales-pipeline record: it resolves the lead's name, email, phone and company (preferring the newly-created Flow contact, falling back to the submission's own raw fields), confirms the organization actually has an open pipeline stage and an active profile to own the deal — exiting quietly if either is missing, rather than creating a malformed record — and then checks for an existing Orbit contact with the same email already attached to an OPEN deal. If one exists, the bridge adds a timeline note to that deal instead of creating a duplicate; otherwise it creates a genuinely new company, contact and deal, sourced as "site," with a next-action reminder one day out.

Both triggers that touch the lead the instant it arrives carry the same explicit safety property, stated directly in their own exception-handling comments: the bridge that hands a lead to Orbit "can never take down lead capture itself." Any unexpected error inside either trigger is caught, logged as a warning for someone to investigate later, and the original submission row still gets saved — a bug in the automation or CRM handoff degrades to "this one lead didn't get its nurture email or its deal yet," never to "the form silently failed to submit."

Someone who submitted a contact-us form two weeks ago, and already has an open deal in Orbit from that first submission, fills out a second form on a different page of the same site — say, requesting a quote. The bridge finds the existing open deal by matching email, and rather than creating a second, competing deal for the same prospect, it adds a timeline note to the one that already exists, so the salesperson sees both signals on a single record instead of two disconnected leads.

A website form submission now reliably becomes a real, queryable contact, an active nurture sequence (when one is configured) reliably fires instead of silently never running, and a qualifying lead reliably reaches the sales pipeline as a deal rather than depending on someone manually re-entering it. And because both triggers fail closed on the side of preserving the original submission, a future bug in either mechanism degrades to a missed nurture email or a missed deal creation — never to a lost lead.

This page describes the two database-level triggers fixed in this release specifically — it does not claim to describe the worker and executor argument-shape fixes deployed in the same release, which live in edge functions rather than a stable migration file and were not re-verified for this page beyond the commit's own record of them. A team expecting every website submission to become an Orbit deal regardless of pipeline configuration will instead find a deliberate, silent skip when the organization has no open stage or no active owner configured — by design, to avoid creating a malformed record.

An automation that looks correctly configured on a settings screen has told you nothing about whether it has ever actually run — a chain with several independent links can look complete at every individual step while never once completing as a whole. Centriu's fix came from tracing one real submission through every step of that chain rather than trusting the configuration screen, naming each of the four points where it silently broke, and closing the two that live in the database with triggers that fail toward preserving the lead, never toward silently losing it.