Write the routing contract first
Define the destination, source label, routing tag, required contact fields, readable intake summary, assignment ID, and owner of the next action before building the form. The contract should also state which responses count as delivered and which errors must be returned to the visitor.
- Name the system that is authoritative for initial delivery
- Define the minimum fields needed to route and review
- Keep optional analytics and ad-platform fields outside the success definition
Normalize and validate on the server
Case Growth Solutions' lead routes keep CRM credentials server-side, normalize phone numbers, validate email and consent, discard honeypot submissions, and construct trusted routing fields on the server. A crafted browser request cannot replace the agency-built attribution block or choose an arbitrary campaign tag.
- Accept a lead only when at least one valid contact path is present
- Bound free text and attribution values before storage or delivery
- Return field-specific errors when the primary system rejects a value
Put workflow signals on the initial write
In the implemented GoHighLevel path, the routing tag travels on the contact upsert because contact-created workflows may evaluate filters at creation time. After a successful upsert, the route also re-applies the tag through the dedicated tag endpoint. The assignment ID and server-built case summary travel with the contact so intake and later reconciliation share the same record.
- Do not depend on a later request for a creation-time workflow condition
- Use a readable summary for intake and structured fields for automation
- Keep the source and assignment identifiers attached when the record moves
Fail closed on delivery and fail open on optional measurement
The primary CRM or approved webhook determines the visitor response. Missing configuration, an unsuccessful provider response, or a network exception returns an error instead of a false success. Warehouse inserts and conversion API calls are scheduled after a successful handoff or bounded so they cannot delay or erase the lead.
- Never show success until the primary destination confirms
- Record failed delivery for triage without sending a conversion event
- Let analytics degrade without hiding a CRM failure
Suppress duplicates without losing first-time inquiries
Case Growth Solutions' implemented duplicate check suppresses only contacts already recorded as successfully delivered inside a configured window. The lookup is bounded and fails open, so an unavailable warehouse does not block a first-time inquiry. The dashboard then exposes CRM failures, review flags, conversion-delivery states, and assignment IDs for follow-up.
- Tie suppression to prior confirmed delivery
- Use stable IDs and explicit idempotency where a downstream system supports them
- Monitor failed, retrying, blocked, and not-configured states separately