By Simon Wright, Digital & Content Marketing Manager, Forte Group
tldr; If you manage forms, own a Salesforce org, or oversee data flows in your organisation, this article is for you. The argument it makes is simple: the decisions you make inside your form builder are data architecture decisions, and they have consequences that reach far downstream.
Picture this. A marketing team at a mid-size financial services firm spends six months building an AI-powered customer segmentation model. The data science team selects the platform, trains the model, and integrates it with the CRM. Leadership signs off. The campaign launches.
The results are poor. Open rates are down. Conversion is worse than the old rules-based approach. The data science team digs in. They trace the underperformance through the model’s feature set, back through the pipeline, back through years of customer records, and they find it. Duplicate contacts. Inconsistent address formats. Phone numbers in email fields. Free-text job titles that range from “CEO” to “chief exec” to “C.E.O” to a blank. Not a modelling problem. Not an architecture problem. A data quality problem that began, quietly and unremarkably, the first time a customer filled in an onboarding form.
The expensive fix; retraining the model, cleansing the CRM, rebuilding the pipeline, took months. The cheap fix had been available for years, sitting inside the form builder.
It’s a story the team at Forte Group keep encountering across client engagements. And it is the story this article is about.
The data lifecycle nobody talks about
Most organisations think about data quality in terms of the systems that store and process data: the warehouse, the lakehouse, the CRM, the analytics platform. Those systems matter. But they are in the middle of the story, not the beginning.
The full chain looks like this:
Collection → Storage → Integration → Mastering → Governance → Analytics & AI
Each handoff is a risk. Data that enters a system dirty does not become clean by passing through a pipeline. It becomes more embedded, more replicated, and more expensive to fix. By the time poor-quality data reaches an AI model or an executive dashboard, it has typically passed through four or five systems, been copied into two or three more, and influenced decisions that nobody can easily trace back to a malformed field on a web form submitted three years ago.
Forrester research puts a number on this: over a quarter of organisations estimate they lose more than $5 million annually to poor data quality, with 7% reporting losses of $25 million or more. What makes that figure particularly striking is where the loss shows up. It rarely appears at the point of failure. It surfaces downstream – as lost revenue, operational inefficiency, compliance exposure, and missed opportunity. The delay between cause and consequence is exactly what makes poor data quality so dangerous, and so easy to underestimate.
The two ends of the chain: collection and continuous governance, tend to receive the least investment relative to the damage they cause. This article focuses on the collection end, where the most effective and lowest-cost interventions live, and connects it to what needs to happen further down the chain to keep quality intact.
Form design is data architecture
This is not a metaphor. When you choose to use a free-text field instead of a controlled dropdown, you are making an architectural decision. When you make a field optional that downstream systems depend on, you are making an architectural decision. When you allow unauthenticated submissions to write records directly into your CRM, you are making an architectural decision. These decisions compound over time, and their consequences are eventually felt far from the form itself.
FormAssembly’s philosophy frames this well: data stewardship begins at the point of collection. The tools to enforce that stewardship; field validation, autosuggest, authentication, e-signatures, conditional logic, are not just usability features. They are data quality mechanisms. Used deliberately, they ensure that what enters your systems is trustworthy from the moment it arrives.
Consider two versions of a healthcare patient intake form. In the first version, the medication field is a free-text input. Patients enter “Lisinopril”, “lisinopril 10mg”, “the blood pressure pill”, and occasionally nothing at all. In the second version, it is an autosuggest field tied to a standardized drug database, with a fallback text entry that is flagged for manual review. The first version is faster to build. The second version produces data that can actually be used; in clinical analytics, in safety monitoring, in insurance processing, without a data cleaning step that costs more than the form itself.
Or consider a financial services onboarding form where address fields accept free text without validation. A customer enters “St.” in one field and “Street” in another. Their spouse, onboarding separately six months later, uses “Str.” The CRM creates three records. The AML system flags a potential duplicate identity. A compliance analyst spends an afternoon on a false positive. Multiply that across thousands of customers and the cost is not trivial, and none of it needed to happen.
The uncomfortable truth is that form builders are making data architecture decisions every day without necessarily thinking of them that way. The goal of this article is to change that framing.
What happens when collection-layer quality is ignored
The financial and operational consequences of poor data quality at the collection layer are not hypothetical. They play out, at various scales, across every industry.
At the extreme end, consider what happened at Unity Technologies in 2022. Inaccurate data ingestion corrupted the datasets used to train advertising-related machine learning models. Faulty data sources introduced errors into predictive targeting and bidding algorithms. Unity reported approximately $110 million in lost revenue tied to underperforming models, delayed initiatives, and the cost of retraining affected systems. The ingestion layer in that scenario is structurally analogous to the collection layer in any enterprise data stack. The mechanism is the same: unvalidated, unverified data entered a system that trusted it, and the consequences propagated downstream before anyone caught them.
The same year, Equifax issued inaccurate credit scores to millions of consumers due to incorrect data values generated by a legacy system. In some cases the errors were significant enough to influence lending decisions. Regulatory scrutiny, class-action litigation, and financial penalties followed.
In 2018, Samsung Securities processed an invalid data entry while attempting to issue employee dividends, mistakenly triggering the issuance of billions of duplicate shares. Insufficient validation allowed the erroneous values to reach downstream trading systems. The issue was identified within minutes; but not before causing market disruption, regulatory penalties, leadership resignations, and an estimated hundreds of millions of dollars in market value loss.
These are high-profile cases. But the underlying mechanism; a data error that validation could have caught, propagating through systems that trusted what they received, is not unique to large enterprises or complex pipelines. It happens wherever data enters a system without adequate controls at the point of entry.
At Forte Group, we encounter smaller versions of this story regularly. The marketing database with 40% duplicate contacts because the web form created a new record every time instead of checking for an existing match. The sales pipeline report that has been subtly wrong for eighteen months because a form field that fed the pipeline stage had its options renamed without updating the mapping. The GDPR compliance audit that revealed consent records were incomplete because the consent field was optional. In every case, the fix was available at the form layer, and was not applied there. Instead, it was applied; expensively, partially, and too late, further down the chain.
What good data looks like before it reaches the warehouse
If collection-layer quality is the first line of defence, what does good practice actually look like in the tools that FormAssembly’s users work with every day?
Control inputs wherever possible. Every free-text field is a liability. Wherever a field maps to a value that downstream systems will use for filtering, segmentation, reporting, or compliance, it should be a controlled input: a dropdown, a radio button, an autosuggest tied to a known list. Free-text fields should be reserved for genuinely open-ended responses; feedback, notes, comments, that will be handled qualitatively or not at all.
Make critical fields required. This sounds obvious, but the number of enterprise forms we encounter where business-critical fields are optional; because “we didn’t want to create friction”, is striking. If a field is used by a downstream system to make decisions, it needs to be populated. Optional fields create sparse data. Sparse data creates gaps. Gaps create incorrect outputs.
Validate at the point of entry. Email format validation, phone number format validation, postcode lookup, date range constraints; these are small configurations that prevent an enormous class of downstream problems. A phone number that fails format validation at the form layer never enters the CRM as garbage. A postcode that resolves to a known address eliminates address inconsistency before it becomes a deduplication problem. IBM describes this principle as “shifting left”; pushing detection, prevention, and remediation closer to the moment data is created rather than waiting for issues to surface downstream. The form is as far left as you can go.
Use authentication to verify who is submitting. Data quality is not only about the accuracy of the values, it is about the trustworthiness of the source. A form submission from an authenticated user with a verified identity carries a different level of trust than an anonymous submission. In regulated industries, that distinction is not optional. In any industry where submitted data influences records that affect real people, it matters.
Treat form versioning as schema versioning. When a form changes, a field is renamed, an option is added to a dropdown, a conditional branch is introduced; the data produced before and after that change may not be directly comparable. Systems that consume that data need to be aware of the change. This is not commonly thought about in form-building contexts, but it is standard practice in data engineering. Connecting the two disciplines here prevents a category of silent data corruption that is very difficult to diagnose after the fact.
Map every field to its destination explicitly. The FormAssembly–Salesforce integration is powerful precisely because it allows deliberate, field-level mapping between form submissions and CRM records. That power comes with responsibility: every mapping should be intentional, documented, and reviewed when either the form or the Salesforce schema changes. Ambiguous or stale mappings are a leading cause of the silent data corruption that data engineers spend significant time diagnosing.
The middle of the chain: Where good data gets tested
Even data that enters a system clean faces quality challenges as it moves through an enterprise. This is worth acknowledging honestly, because it explains why good collection hygiene is necessary but not sufficient.
When a clean form submission enters Salesforce, it does not exist in isolation. It joins a data estate that includes records from other sources: an ERP system, a billing platform, a support tool, a marketing automation database, a spreadsheet someone maintains in a shared drive. Each of those sources has its own conventions, its own data quality characteristics, and its own definition of what a “customer” or a “contact” or a “product” is. When those records are brought together; in a data warehouse, a lakehouse, or an analytics platform; the question of which record is right, which values should be trusted, and which records refer to the same entity becomes genuinely difficult to answer.
This is the central failure of the modern data platform: the industry solved data movement, but did not solve data meaning. A data lake can bring records physically closer together without resolving the question of which version of a customer is correct. Integration makes data visible. It does not make data trustworthy.
This is where Master Data Management and data governance come in; disciplines that try to answer which record is authoritative, what happens when two systems disagree, and how entity relationships are maintained over time. They are powerful and necessary. They are also expensive, slow, and reactive. Fixing a data quality problem in the governance layer costs an order of magnitude more than preventing it at the form. The middle of the chain is where you pay for collection-layer decisions you made years ago.
If you use FormAssembly to feed Salesforce, the most immediately actionable implication of this is how you configure the Salesforce integration behaviour. Using update-or-insert logic; checking for an existing record before creating a new one, is a small but meaningful contribution to the continuous integrity of the CRM. Creating a new record on every submission, without checking for a match, is a reliable way to produce the duplicate-contact problem that plagues almost every mature Salesforce org and is genuinely expensive to clean up. Beyond the connector behaviour itself, the field-level mapping interface is where the quality contract between your form and your CRM is written. Every mapping should be intentional and reviewed whenever either the form or the Salesforce schema changes; a stale or ambiguous mapping is one of the most common sources of silent data corruption we diagnose in client environments. FormAssembly’s conditional logic and validation rules are your levers for enforcing that contract at source: use them to lock down the values that reach Salesforce, not just to improve the form experience.
More broadly: what happens to data after it leaves FormAssembly is shaped significantly by decisions made inside FormAssembly. The data that enters a pipeline inherits the quality characteristics of the collection layer. Those characteristics; field completeness, value consistency, structural conformity, travel with the data wherever it goes.
When AI enters the picture, the stakes change
Everything described above becomes significantly more consequential when AI systems are involved. Not because AI introduces new categories of data quality risk, but because it amplifies existing ones at speed and scale.
AI systems do not evaluate the trustworthiness of their inputs. They consume what is available, reason from the patterns they can find, and produce outputs that carry the authority of an automated system. When the underlying data is inconsistent, incomplete, or biased, the model does not know that its foundation is weak. It produces outputs with the same apparent confidence regardless.
Salesforce found that 84% of data and analytics leaders say their data strategies need a complete overhaul before their AI ambitions can succeed. A Cloudera and Harvard Business Review Analytic Services study found that only 7% of enterprises say their data is completely ready for AI, while 73% struggle with AI data preparation.
Those figures describe a real and widespread problem. But the response to them is often framed in terms of data infrastructure: better pipelines, better governance frameworks, better observability tooling. Those investments are necessary. What is less often said is that a meaningful portion of the AI readiness problem can be addressed; cheaply, quickly, and without a data engineering engagement, by improving the quality of data at the collection layer.
The AI model that will eventually consume your customer data is only as good as the records that feed it. Those records are only as good as the systems that created them. And for a significant portion of enterprise customer data, those systems are web forms.
Gartner predicts that through 2026, organisations will abandon 60% of AI projects unsupported by AI-ready data. Before asking whether your AI infrastructure is ready, it is worth asking whether the data entering your systems through your collection layer is ready to become AI training data or AI grounding data; because that question has an answer, and the answer is actionable right now.
Building an organisation that treats data quality as a shared responsibility
The final point is organisational, not technical.
Data quality is not a data team problem. It is not an IT problem. It is not a compliance problem. It is a business problem that runs the full length of the data lifecycle; from the person who designs the intake form, to the Salesforce admin who configures the integration, to the data engineer who builds the pipeline, to the analyst who builds the dashboard, to the executive who makes decisions from it.
Each of those people makes choices that affect the quality of the data everyone downstream relies on. The challenge is that most of them do not think of their choices in those terms. The form builder is thinking about user experience and completion rates. The Salesforce admin is thinking about field mapping and record types. The engineer is thinking about throughput and latency. None of them is wrong. But without a shared understanding of what data quality means across the full chain, each of them can make individually reasonable decisions that collectively produce a data estate that nobody trusts.
The practical implication is this: data quality needs owners at every layer, not just in the data team. Someone needs to be responsible for the quality standards applied at the collection layer; the validation rules, the controlled vocabularies, the required fields, the authentication requirements. That person may be a Salesforce admin, a marketing ops manager, or a product owner. It does not matter what their title is. What matters is that the responsibility is explicit, and that they understand how their decisions propagate downstream.
A few concrete starting points for FormAssembly users who want to raise the quality floor:
Audit your existing forms. Identify every field that accepts free text where a controlled input would serve the downstream use case better. Identify every field that is optional but feeds a system that treats its absence as an error. Identify every form that creates new CRM records without checking for an existing match. These audits consistently surface a small number of high-impact issues that are straightforward to fix.
Define what “good” looks like for your most critical data. Data quality metrics without agreed standards are decorative. For the customer fields that matter most; name, email, address, consent status, account type, define what a valid record looks like. Then configure your forms to enforce it.
Connect form changes to data change management. When a form field changes, treat it the way a data engineer would treat a schema change: document it, communicate it to downstream consumers, and verify that existing integrations still behave as expected. This single practice prevents a category of silent data degradation that is disproportionately common and disproportionately expensive.
Bring data quality into business conversations. The IBM research is clear: the cost of poor data quality is a business cost, not a technical cost. Framing it that way, in terms of revenue impact, compliance exposure, and AI readiness, is what moves it from a backlog item to a business priority.
The question to ask before your next AI initiative
Before any organisation invests in AI agents, predictive models, or advanced analytics, there is one question worth asking honestly.
Do we trust the data those systems will act on?
If the answer is uncertain, the starting point is not the AI platform. It is not the data warehouse. It is the moment data first enters the organisation, which, for a significant portion of enterprise data, is a web form.
The most effective interventions in data quality are the least expensive ones, and they are available at the point of collection, before the damage begins. Good form design, enforced validation, deliberate field mapping, authenticated submissions: none of these require a multi-month data engineering engagement. They require the Salesforce admins, marketing ops managers, and operations leads who build and own forms to understand that their configuration decisions are, in a very real sense, data architecture decisions; and that they are the first data engineers in the pipeline, whether they think of themselves that way or not.
