What Is a Workflow Data Contract? A Field Guide for AI Marketing

The scoring step returns the same number for every lead. Personalization fields go out blank. Enrichment runs and still produces no company data on a large share of contacts, sometimes around two in five. None of those are model failures. They are handoff failures. Nobody wrote down what each step was supposed to receive before the next one ran, so the workflow finished and finished wrong.

Gartner's February 2026 press release, drawing on a Q3 2024 survey of 248 data management leaders, found that 63% of organizations lack the data practices AI needs, and that 60% of AI projects without AI-ready data will be abandoned by 2026. A data contract is how a marketing workflow stays out of that 60%. The wider picture is why a tool that hands nothing onward fails.

What is a workflow data contract?

It is a written specification for each handoff. It names the fields the next step requires, the types it expects, and how complete those fields have to be before the step is allowed to run. If the step receives less than that, it stops, branches to a fix, or flags the contact. It does not continue on incomplete input and produce a worse output that still looks successful.

The idea comes from software, where a producer and a consumer agree on the data between them. The form is a producer. Enrichment is a consumer. After enrichment runs, that step becomes the producer for scoring. Every step is both. Marketing teams almost never write the agreement down, so it disappears when the person who built the automation leaves, or when someone edits a workflow without checking what sits downstream.

The contract names the fields, the null policy, and the check.

A complete contract covers three things at each handoff. Required fields and types: email as text, company size as a number, intent score as a number from 0 to 100. A null policy: required fields halt or branch when missing, optional fields use a named fallback. Validation: email matches a normal format, the score stays inside 0 to 100, a first name is not only spaces. Without those, the automation platform decides, and its default is almost always to proceed and render nothing in the blank fields.

Write the three as a table the next owner can read without opening the workflow. One row is one field. The columns are the name, the type, whether a blank stops the step, the check the value has to pass, and the branch that runs when it fails. Two people reviewing that table can name every failure before a contact ever runs through it. The form produces an email, a name, and the identifier of what the person requested. Enrichment consumes the email so it can derive a company domain, then produces a company name, a size, an industry, and a status flag. Scoring consumes those and produces a number. Outreach consumes the number, the name, and the flag. Each of those sentences is a row, or several rows, in the contract.

When the person who built the automation leaves, an unwritten agreement leaves with them. The next edit renames a form field, the downstream step keeps its old assumption, and the run log still shows a completed execution. The contract is the page you reopen when you add a step, because the new step consumes whatever sits immediately before it and produces whatever the step after it will read.

Why do workflows break at the handoff?

Software that breaks gives you an error. A marketing workflow that breaks at a handoff gives you a generic email, a score that does not match the lead, or enrollment in the wrong sequence. None of those raise an alert. Quality drops until someone notices the revenue weeks later.

IBM's June 2025 study of 2,500 executives across 18 industries found that 79% of enterprises have adopted agents in some form, only 11% are running them in production, and 26% are confident their data can support revenue that depends on AI. The gap between adoption and production is mostly a data problem.

One missing field becomes four wrong steps.

Missing fields cascade. If capture does not collect a company domain, enrichment cannot look up the firm. Without that, scoring has no company size or industry and assigns a default. With a default score, segmentation sends the lead down the wrong path. Four steps of error from one missing field, and nothing logs a warning. How that spreads through scoring is in output quality errors.

Follow one contact to see why the warning never appears. Capture stores an email and a timestamp and stops. Enrichment calls a lookup with no domain and writes empty values for size and industry. Scoring applies the weight it was given for an unknown company, which is the same number it would write for a different unknown company, so the two contacts look identical. Segmentation reads that number and enrolls both in the path reserved for a low-intent lead. The person who submitted a specific request is now in a sequence written for someone who barely raised a hand. The log says each step completed, because completion was defined as "the step ran," not as "the step received what it required."

The platform marks a blank field as a finished run.

Platforms such as n8n, Make, HubSpot workflows, and Zapier run on whatever data is present. They do not error when a required field is absent. If the personalization tag is the company name and the field is blank, most platforms render the blank and mark the run successful. The workflow completed. The output is wrong. The platform was never given a definition of wrong.

The tag is often written as {{contact.company_name}}. The platform replaces the tag with the value on the contact. An empty value is still a value the platform can substitute, so the message goes out with a hole where the company should be, and the execution is marked complete. The same thing happens with a first name, a meeting time, or the name of the asset they requested. Until the contract says an empty company name is a failed handoff, the platform has no reason to stop. It was asked to send, and it sent.

A stub contact can look finished at every step.

A stub contact is an email and a timestamp. If the domain is Gmail or Yahoo, the lookup returns nothing, enrichment writes nulls, scoring assigns a near-zero score from behavior alone, and the lead enters a long follow-up. Someone who might have been a direct conversation goes quiet while every step reported success.

The status flag is how you stop treating that miss as a company. Enrichment writes a value such as "no match" instead of leaving the company name blank or inserting a placeholder. The next step is not allowed to personalize from a company name when the flag says the lookup missed, and it is not allowed to treat the near-zero score as a real qualification. The contact goes to a review list with the failing field named, which is a visible stop, rather than into a sequence that assumes they are early and cold.

What does each step need from the one before it?

The common chain is capture, enrichment, scoring, segmentation, and outreach. How to rank the steps is in the 60-minute map. How the first handoff gets wired is in the booking-to-CRM worked example.

Capture has to hand enrichment five fields.

Capture has to produce five fields for enrichment to do its job: a valid email, a name, UTM source and medium, a submission time, and the identifier of whatever they requested. Enrichment needs the email, so it can derive a company domain, and the identifier, so later steps know the intent. If capture does not pass UTM source, every later step runs without first-touch attribution, and you cannot say which channel produced the lead.

Each of those five fails in a different way, which is why the contract names them separately. An email that is present but malformed, with a missing dot or a space in the middle, will pass a "field is known" check and still break the lookup. A name that is only spaces looks populated in a CRM export and fails a whitespace check. A submission time that is missing makes it impossible to say whether the lead is inside the window you use for speed-to-lead. The identifier of the request is what later personalization quotes. Without it, the outreach step can greet the person and still cannot say which asset they asked for, so the message becomes generic even when the name is right.

Enrichment has to hand scoring a status flag.

Enrichment has to produce a company name, a domain, a size, an industry, and a status flag that says whether the lookup worked. Scoring consumes all five. Size and industry carry the most weight in most business-lead models. If either is missing, a score of 45 on an unenriched contact and a score of 45 on an enriched contact are not the same state. Routing them at the same threshold breaks the route.

The status flag is the field teams leave off the contract because the other four look like the data. They are not usable without it. A company name can be a real lookup, a placeholder a fallback inserted, or a value someone typed on the form that was never checked. Scoring cannot tell those apart unless enrichment says which one it is. When the flag is missing, a model that expects a number for company size will also accept a blank as zero, or a word such as "large" as no number at all, and it will still return a score. That score then sits on the contact next to scores that were computed on complete input, and a threshold treats them as the same kind of lead.

Outreach needs six fields before the message can be specific.

Outreach needs six fields for a message that is actually specific: first name, company name, industry, intent score, what they requested, and the enrichment status. The status flag is the one teams omit. Without it, the outreach step cannot tell a real company name from a placeholder a fallback inserted, so it cannot match how specific the message should be to how good the data is.

Match the message to the flag on purpose. When the flag says the lookup worked, the message can name the company and the industry. When the flag says the lookup missed, the message uses the request they made and does not invent a company. When the score is missing, the message does not imply a priority the scoring step never assigned. That is a smaller set of templates, and it is the set the contract allows. A single template that always inserts company and industry will render holes, or worse, will insert the fallback text as if it were researched.

How do you write the contract?

You do not need an engineering project. The document is a table: one row per handoff, with fields, types, null policy, and validation. A first draft for five steps takes two to four hours. The input is a conversation with whoever built the automation, plus the CRM field definitions for everything the workflow reads.

Required fields stop the step, and optional fields use a named fallback.

Required fields halt or branch when they are absent. If enrichment requires a company domain and capture did not collect it, the workflow branches to a step that collects the domain instead of attempting a lookup with no key. Optional fields use a named fallback. If first name is missing, outreach uses a salutation you wrote in the contract. Without that, the platform chooses, and it usually chooses an empty string.

An empty string is the fallback you get when nobody chose one, and it is the wrong fallback for almost every personalization field. "There" in a greeting is a choice you can defend. A blank greeting is a broken sentence the reader sees. Write the fallback in the contract so a later editor does not "clean up" the template by deleting the word and leaving the hole. The same rule applies to UTM medium. If you decide a missing medium may continue, name the value you will store, such as "none," so reporting can separate "we know it was direct" from "the field was never passed."

A validation gate sits between the producer and the consumer.

A validation gate runs after the producing step and before the consuming step. It checks that required fields are present, types match, and values sit in range. In n8n that is an IF node. In Make, a filter. In HubSpot, a branch on "property is known." The gate catches the violation before it spreads and sends the failure to a named branch that logs the type.

Place the gate where the failure is still one field, not four. After the form trigger, check that email is non-empty and matches a normal format, and that the request identifier is non-empty and belongs to a known set. After enrichment, check that the status flag is not "no match" before scoring is allowed to treat company size as real. Contacts that pass continue. Contacts that fail go to a review branch, and the specific failing condition is written as a CRM note so the person who fixes it does not have to re-run the workflow to learn which check failed.

Five rows can cover the capture handoff.

A capture-to-enrichment contract can start with five rows. Email, text, required, must match a normal email format, otherwise the invalid-email branch. First name, text, optional, fallback "there" in the greeting. UTM source, text, required for attribution, otherwise a branch that still captures the lead and flags the missing source. Submission time, datetime, required. The identifier of the request, text, required, because enrichment and later personalization both read it.

The workflow does not run enrichment if email or the request identifier is absent. Those five rows are a complete contract for one handoff. They are an operating frame for the capture step, not a client result. The same shape, with different fields, is what you write for enrichment to scoring and for scoring to outreach. If a row has no "on failure" cell, that row is not finished, because the platform will choose for you.

How does a contract stop a cascade?

The contract turns a silent success into a visible stop. The platform can no longer mark a blank company name as a finished personalization, because the gate already branched. You fix one field at the source instead of discovering four broken steps in a revenue review. McKinsey's 2025 analysis of agentic marketing workflows found that 80% of companies cite data limitations as the main roadblock to scaling this kind of AI, that interoperability between systems binds harder than model ability, and that fewer than 10% of CMOs have deployed end-to-end AI workflows that produce measurable value. The contract is the interoperability, written down.

An early stop is visible, and a late miss looks like success.

Under an early stop, a contract violation halts the workflow at the step where it happened and sends the contact to a visible review list with the failing field named. Under a late silent miss, which is what you get when no contract is written down, the contact passes every step with whatever data it has and produces a corrupted output that looks like a completed run.

The early stop gives you a bounded list: missing domain, missing phone, unrecognized request. The late miss gives you a population of contacts with weakened scores, blank personalization, and the wrong sequence, and that population stays invisible until you audit it. A failure case we use to explain the late miss is a large share of enriched contacts, sometimes about a third, whose company size is zero because the lookup missed and the step wrote the default integer instead of flagging the miss. That share is illustrative, not a client result. The contract forbids that write. A miss is a status, not a zero.

The gate writes the failing condition where a person can see it.

In n8n, the gate after the form trigger is an IF node. It checks that email is non-empty and valid, that the request identifier is non-empty and in the known set, and that the enrichment status after the lookup is not "no match" before scoring continues. Contacts that pass all three go on to scoring. Contacts that fail one of them go to the review branch, and the specific check that failed is written as a CRM note.

That note is the difference between a list a person can clear and a list that says only "needs review." "Email failed format" is a different fix from "request identifier was not in the known set," and both are different from "enrichment returned no match." If the note names the check, the person who owns the list can fix the field or fix the form. If the note only says the workflow branched, they have to open the execution log for every contact, which is how a review list stops getting cleared.

How is this different from a CRM field map?

A field map says where a value is stored. A contract says what happens when the value is missing, the wrong type, or out of range, and which step is allowed to run next. A map can be complete and the workflow can still proceed on a blank. The contract is the rule that refuses to proceed.

A field map cannot see blanks, bad types, or the next action.

A CRM field map is the schema: the properties on a contact or a deal, their types, and the picklist values. It cannot tell you whether a field is populated on the contacts entering a specific workflow. A field can exist in the schema and still be blank on a large share of net-new contacts. A company-size property that exists for everyone and is blank on about 70% of contacts created this month is illustrative, not a client result. The map says the property is there. The contract asks whether this workflow's contacts had it at the moment the step ran.

A map also cannot tell you whether a value is usable by the step that reads it. A company-size field that contains the word "large" matches a text property and violates a contract that expects an integer. Both statements are true at once. Schema validation passes. The scoring step then either skips the weight or coerces the word into a number you did not intend. And a map cannot say what the workflow should do when the field is absent. It documents that the property exists. The contract documents the behavior when the property is empty, the wrong type, or outside the range the next step can use.

A person can fill a gap that a machine will not.

If the stack is fully manual, a field map is enough. A person reading a contact fills gaps, applies judgment to an ambiguous value, and flags a contact that needs more information before anyone sends a message. When you replace that reader with an automation rule or an agent, the judgment disappears at the moment you needed it. The contract replaces the judgment with an explicit rule. You do not need a contract for a workflow a person operates at every step. You need one for every workflow a machine operates without a person reviewing the handoff.

That line is the one to use when someone asks for a contract on a spreadsheet a person still checks by hand. Spend the two to four hours on the path where no person sees the contact between capture and the message. That is where a blank becomes a sent email. The manual path can wait until the day you remove the person from the middle of it.

How do you audit the workflows you already have?

Pick one live path. For each step, write the fields it reads and the fields it writes. Mark any field the next step needs that the previous step does not guarantee. Run the last 30 days and count how often those fields are blank. Anywhere the blank rate is high, and the platform still reports success, you have a missing contract. Start with capture to enrichment. That is where a missing domain becomes a default score becomes the wrong sequence.

Count the blanks at the moment the step ran.

Pull any running workflow and list every field each step reads. Then pull a 30-day sample of contacts that ran through it and check what share had each field populated when the step executed. The check is not "is the field filled on the contact today." A person, or a later workflow, may have filled it after the step already ran on a blank. You want the value at execution.

The audit produces two outputs. One is a population rate for each field the step treats as critical. The other is the list of contacts that ran through with one or more required fields blank at that moment. Treat a required field populated on fewer than 90% of those contacts as a broken contract, and treat a high-weight optional field populated on fewer than 70% as a contract that needs an explicit fallback. Those two bands are illustrative, not a client result. Do not start a nurture sequence on a contact that failed the contract. Route to the review list, name the missing field, and let a person fill it.

Three questions surface every broken handoff.

For each step, ask three questions. What field does this step read that the previous step must have produced? What share of contacts that reached this step had that field populated when the step ran? What did the step do with contacts where the field was absent?

If you cannot answer the third question from a document, the contract does not exist in writing. It exists only in the platform's default, which is almost always to proceed and render nothing. That default is the source of most silent failures in a multi-step marketing workflow. The contract specifies what happens when the data is incomplete, so the failure shows up as a branch and a note rather than as a successfully completed log line. If you want that audit done against the path that actually books meetings, get your free Systems Plan. We will name the handoff that is finishing wrong before we talk about a new tool.

How we know this.

Gartner, February 2026 press release, Q3 2024 survey, n=248: 63% lack AI-ready data practices, and 60% of AI projects without that data are forecast to be abandoned by 2026. IBM, June 2025, n=2,500, 18 industries: 79% have adopted agents in some form, 11% are in production, 26% are confident the data can support AI-enabled revenue. McKinsey, 2025, "Reinventing marketing workflows with agentic AI": 80% cite data limitations, interoperability rather than model ability is the binding constraint, and fewer than 10% of CMOs have deployed end-to-end workflows with measurable value. The two-in-five enrichment miss in the opening is a failure pattern this post uses as an example, not a study statistic. The field lists, the two-to-four-hour draft, the 90% and 70% audit bands, the 70% blank-schema illustration, and the company-size-of-zero failure case are an operating frame, not a client result.