How to automate form data routing: everything before the routing

Automate form data routing by cleaning each submission before you route it: filter spam, validate the contact details, then classify by message content and send it to the right owner. Routing itself is close to trivial once the submission is clean. Most of the difficulty is upstream, because public forms attract spam, contact details contain typos, and the free-text field holds everything from a sales enquiry to a support request to a job application. Skip the cleaning and you deliver unusable data to four teams at once, which is worse than the inbox it replaced.

Key takeaways

• Filter spam and validate contact details before any routing rule runs.
• Route on the message text, not on the dropdown, because people pick the wrong option consistently.
• Define "the right team" as owner, individual, priority and system of record, and check for an existing account owner first.
• Send an acknowledgement immediately, from a monitored address, saying who will reply and when.
• Persist the raw submission first, so a downstream failure delays a submission instead of losing it.

What we'll cover

• Spam is the majority problem
• Validating what you will need later
• What "the right team" actually means
• Building it with CodeWords
• Routing on content, not on a dropdown
• The acknowledgement
• Designing the form to reduce the work
• Measuring the routing rather than trusting it
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Spam is the majority problem

Spam is the first problem to solve, because any public form attracts automated submissions, and their volume does not track your traffic. Four cheap checks remove most of it.

A honeypot field is a hidden input that a human never fills and a bot usually does. It costs almost nothing.

Timing is a strong signal. A form completed in under a second was not completed by a person.

Content patterns catch more: links in a name field, unrelated languages, the same message from many addresses.

Do not silently discard. Route suspected spam to a low-priority queue that somebody glances at, since a false positive is a lost customer.

Measure the rate. A sudden change usually means something new has discovered your form, and you want to know before the team notices the noise.

Validating what you will need later

Validate the details the team will need later, and tell the person at once if something is wrong.

Verify the email address exists, not just that it looks valid, since a typo means your reply never arrives and the submission is wasted.

Normalise phone numbers to a standard format with a country, or the sales team cannot dial them.

Check the company domain against the email, which enriches the record and identifies personal-address submissions.

Detect the empty submission: a name, an address and nothing meaningful in the message. It needs a different response from a real enquiry.

Preserve the raw submission exactly as received, alongside anything you derived, permanently.

Tell the person immediately if something is wrong, while they are still on the page, rather than after they have left.

What "the right team" actually means

"The right team" means six decisions, because the phrase usually collapses several questions into one.

• Which team owns the response: sales, support, partnerships or recruitment.
• Which individual within it, since a team queue is slower than a named person for anything with a response expectation.
• What priority, which for inbound enquiries is often more consequential than the destination.
• What the system of record is: the CRM, the helpdesk or the applicant tracker. These have different lifecycles, and duplicating across them causes trouble.
• Whether it duplicates an existing conversation, which is common and routinely missed.
• Whether anybody already owns the account. This overrides every other rule, and ignoring it most annoys both the customer and the account owner.

Building it with CodeWords

You build form routing in CodeWords by describing the validation, classification and destinations to Cody, the automation builder. CodeWords connects to 3,000+ integrations (CodeWords pricing page, 2026), so the form provider, the CRM, the helpdesk and your channels can meet in one automation.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody: the validation, the classification, the destinations and the acknowledgement.
3. Authorize the connections: the form or webhook source, the CRM and the helpdesk.
4. Describe the exceptions: suspected spam, an existing account, an ambiguous submission, a submission in another language.
5. Run it against last month's submissions and check the classification against where they actually ended up.

You describe the outcome; Cody builds it, connects it, and deploys it. The Free plan costs $0 and covers light use, Pro is $39 per month ($33 billed yearly) and Business is $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

Routing on content, not on a dropdown

Route on the message text, because people choose the wrong dropdown option consistently, usually the first one or whichever sounds likely to get a fast response. The text is more reliable than the field, and a disagreement between the two is itself a signal worth acting on.

Extract the intent, not just the topic: an evaluation, a problem with something they already have, a question about pricing, a partnership approach.

Detect urgency from the content (an outage, a deadline, a contract date) rather than from a priority field they chose.

Handle the multi-intent submission by routing on the primary intent and noting the rest, rather than splitting it.

Return a confidence score and send low-confidence submissions to a human triage queue rather than guessing.

The acknowledgement

The acknowledgement determines how the submission feels to the person who filled in the form, and teams most often leave it as a default. Send it immediately and make it specific.

Send it immediately, not on the next run of a scheduled job, since a delay reads as nothing having happened.

Say what happens next and when: who will reply and in what timeframe.

Confirm what they told you, briefly, which catches the case where they filled in the wrong thing.

Give an alternative for urgent cases, since somebody with a real emergency should not wait in a queue.

Do not promise a timeframe you will not meet. An unmet promise is worse than a vaguer one.

Send it from a monitored address. The classic failure is a no-reply acknowledgement to which the customer replies with the actual details.

Designing the form to reduce the work

A better form reduces routing work: fewer fields, a free-text message, and no fields nobody uses.

Use fewer fields. Every extra field is a drop-off and a field somebody fills in badly.

Ask for free text rather than trying to structure everything, because the message is where the routable information is.

Drop the fields you do not use. Most forms collect two or three things nobody has looked at.

Validate in the browser for format, and on the server for everything that matters.

Do not require a phone number unless you will call, since people most often falsify that field.

Keep the form accessible, with real labels and sensible error messages. Accessibility is an obligation and also helps completion.

Measuring the routing rather than trusting it

Measure routing accuracy deliberately, because a routing automation is confident by construction and nothing in it notices when it is wrong.

Track reroutes. Every submission a human moves to a different destination is a free labelled example of a mistake.

Watch first response time by destination, since a slow queue is a routing problem too: the submission arrived somewhere nobody is watching.

Sample the spam queue weekly, because a false positive there is a lost customer and nothing else surfaces it.

Compare intent against outcome. Submissions classified as sales enquiries that never become opportunities may be misclassified, or may come from a different audience than you think.

Report the triage queue size, which shows how much the classification is doing.

Review the rules quarterly against the reroute data. The mix of submissions changes as marketing changes, and a rule set tuned a year ago describes an older audience.

Making it survive

A durable routing flow never loses a submission.

Make it idempotent on a submission id, since form webhooks retry.

Persist first, process second, so a downstream failure delays a submission rather than discarding it.

Alert on zero submissions for a set period, since a broken form looks exactly like a quiet week.

Handle the destination being down by queuing rather than failing the submission.

Report the outcome: submissions received, classified, routed by destination, and held for triage.

Limits worth knowing about

Classification is imperfect, particularly on short or vague messages, which is why a triage queue is necessary.

Email verification is probabilistic, and some valid addresses will fail a strict check.

Personal data obligations apply from the moment of submission, including retention and the right to access.

Consent language matters if submissions feed marketing, and that consent differs from consent for the enquiry itself.

Form builders vary in what their webhooks include, and some omit the field metadata you need to interpret the values.

What to build first

Build the acknowledgement first, with validation in front of it. Confirm receipt immediately, say who will respond and when, and catch the invalid email address while the person is still on the page. It is the highest-impact part of the flow for the person who filled in the form, and it is the part most likely to be a default nobody has read.

Two habits make the difference. Persist the raw submission before doing anything else, since every other failure becomes recoverable once that is true. And route on the message text rather than the dropdown, because people pick the wrong option consistently and the gap between what they chose and what they wrote is useful information.

Frequently asked questions

What is the biggest problem with public form routing?

Spam is the biggest problem with public forms. A honeypot field and a submission-timing check remove much of it at almost no cost. Route suspected spam to a reviewed queue rather than discarding it.

Should I route on the dropdown the user selected?

No. People pick the wrong option consistently, usually the first one or whichever seems likely to get a fast response. The message text is more reliable, and a disagreement between the two is itself a signal.

What should be validated at submission time?

Validate that the email address exists, normalise phone numbers with a country, check the company domain against the email, and detect effectively empty submissions. Tell the person while they are still on the page.

What does "the right team" actually mean?

"The right team" means four decisions: which team owns the response, which individual, what priority and which system of record. Two overrides apply: whether the submission duplicates an existing conversation and whether somebody already owns the account.

How important is the acknowledgement?

The acknowledgement matters more than the destination for how the submission feels to the sender. Send it immediately, say who will respond and when, confirm what they told you, and use a monitored address rather than a no-reply one.

What should happen to ambiguous submissions?

Send ambiguous submissions to a human triage queue with the confidence score attached. Guessing on a low-confidence classification sends submissions to the wrong team, where they sit.

How many fields should a form have?

A form should have as few fields as the team actually uses. Every extra field is a drop-off and a field somebody fills in badly, and most forms collect two or three things nobody looks at.

How do I avoid losing submissions?

Persist the raw submission before processing anything. After that, every downstream failure delays a submission rather than discarding it.

How do I know the routing is correct?

Track reroutes, because every submission a human moves is a free labelled example of a mistake. Also watch first response time by destination, since a submission that arrived where nobody is watching is a routing failure too.

Why sample the spam queue?

Sample the spam queue because a false positive there is a lost customer and nothing else surfaces it. A weekly glance is enough.

Related reading

• Automating lead capture from a website
• Automating product feedback categorisation
• HubSpot and CodeWords