The MQL Gate Built Lighter Than Its Design
Marketo ran the whole inbound MQL flow as one orchestrator campaign: enrichment, segmentation, scoring, a five-minute wait, then a stamp marking the record marketing-qualified. HubSpot has no single-campaign equivalent, so the chain became a suite of separate workflows. The documented design held the stamp behind a seven-field readiness gate; the version running today stamps once inbound type reads MQL, and the gate question is still an open decision rather than a closed one.
Executive Summary
Context
The same global enterprise SaaS company rebuilding its Marketo instance on HubSpot depended on the process marking a record marketing-qualified before Salesforce routing acts on it, carrying that process over without the single campaign that used to hold every step together.
What We Built
We rebuilt Marketo's single orchestrator campaign as a chained suite of HubSpot workflows ending in the same MQL stamp. The documented design held that stamp behind a multi-field readiness gate; the version running today checks one field, inbound type, plus merge and test exclusions, and stamps as the orchestrator's last step after the same five-minute wait Marketo used.
Tech Stack
- HubSpot
- Salesforce
- LeanData
Not a fit if your MQL gate has no documented version to reconcile against: the value here is naming a real gap between a specified design and a lighter build, not assuming a rebuild matches its own specification on the first pass. It also assumes downstream routing can run against an openly unresolved go or no-go decision.
The Challenge
Marketo held every step of MQL qualification inside one orchestrator campaign, chaining enrichment, segmentation, scoring, a five-minute wait and the stamp itself. A separate, marketer-controlled sync step held the record back from Salesforce until that chain finished. HubSpot's native Salesforce connector removes the held-back step: it syncs field by field, close to real time, the moment a field changes. A record can reach Salesforce routing and the MQL History object before every field the documented gate expected is populated, a failure mode the old platform's single manual sync step did not allow.
Our Approach
The rebuild splits Marketo's one campaign into a chained suite of HubSpot workflows ending in the same mql_date stamp. Documentation specified a readiness gate checking several fields, among them country, company size segment, inbound type, MQL lead source, MQL source program and inbound tier, all required non-null before the stamp could fire. In early July the team instead shipped a lighter, sequenced version: the stamp fires as the last step, after the same five-minute wait, once inbound type reads MQL and merge or test records are excluded.
LeanData, the routing tool on the Salesforce side, reads mql_date and the segmentation fields HubSpot writes to route the lead; the near-real-time sync gives it a narrower window to see a complete record than the documented gate was built to guarantee. A status update dated August 5 named the gap between the two versions and asked for an explicit go or no-go decision, one the available material does not show as made.
Impact
One orchestrator campaign becomes an inspectable suite
Marketo's single campaign, opaque past its own canvas, is now a set of discrete HubSpot workflows, each holding a named piece of the enrichment-to-stamp chain.
The five-minute wait carried over unchanged
The wait step Marketo used before scoring settled carried into the HubSpot rebuild unchanged, so a timing behaviour marketers already knew did not shift with the platform.
The readiness-gate gap is named, not buried
Rather than let a lighter build quietly stand in for the documented design, a status update named the exact fields the running gate no longer checks and asked for an explicit decision.
Routing has a named point of incomplete-record risk
Because HubSpot's sync moves field by field in near-real time, the rebuild makes explicit where a downstream system such as Salesforce routing could act on a record before every gate field is populated.
One campaign chained enrichment, segmentation, scoring, a five-minute wait and the MQL stamp, held back from Salesforce by a marketer-controlled sync step until the chain finished.
The specified design checked several fields, among them country, company size segment, inbound type, MQL lead source, MQL source program and inbound tier, requiring all non-null before the stamp could fire.
What ships today stamps mql_date as the last step, after the same five-minute wait, once inbound type reads MQL and merge or test records are excluded, without checking the other named fields.
A status update dated August 5 named the gap between the documented gate and the lighter version and asked for an explicit go or no-go, a decision the available material does not show as made.
Marketo (legacy) MQL gate Sync & routing Marketo orchestrator 00. Inbound MQL Sequence Documented gate (spec) 6 fields, all non-null Built check: inbound type plus merge/test exclusion MQL stamp mql_date, mql_date_time HubSpot Salesforce sync field-level, near real-time Salesforce routing MQL History object LeanData reads mql + segment fields spec: gate before stamp documented design specified a 7-field mql_ready gate MQL, last step Inbound Type contains MQL, last step after wait path not taken documented design specified a 7-field mql_ready gate gate passes only gates on Inbound Type contains MQL plus exclusions mql_date stamped mql_date stamped, immediately followed by SFDC sync field-level sync HubSpot's field-level, near-real-time sync incomplete-record risk failure can fire against an incomplete record reads mql fields mechanism 4
FAQ
The stamp firing on time is a different question from whether every field a downstream system expects is populated when it fires. HubSpot's Salesforce sync moves field by field in near-real time, so a record can reach routing before fields the documented gate required are set, a risk the old platform's held-back sync step did not carry.
The wait sits before scoring settles, a step separate from the gate in question, so carrying it over kept a known timing behaviour in place while the gate design was still being decided.
