Start with the decision the form is meant to support
Write down what the visitor is asking for and what the receiving team needs to decide. A contact form, a project brief and a support request have different purposes, so they may need different fields and destinations. Do not ask for information merely because the CRM has a field available.
The ICO's current guidance on data protection by design says organisations should consider privacy from the design stage and limit personal information to what is necessary for the purpose. Map the information, purpose, recipient and retention expectation before adding a field or connecting another system.
Map each field to its meaning and destination
Create a field map with the public label, required or optional state, validation rule, CRM property, access group and downstream use. Use a controlled set of values where the team needs consistent reporting, and explain what happens when a visitor does not fit those values.
If the form offers a separate marketing choice, describe it clearly and keep it distinct from the information needed to answer a service enquiry. Ask a privacy professional to review the lawful basis and notices for the actual processing rather than treating an integration diagram as a compliance decision.
- Purpose and minimum fields
- Validation and error messages
- CRM owner, queue and assignment rules
- Acknowledgement and expected response route
- Retention, access and deletion owner
| Synthetic form value | Validation and CRM property | Owner | Confirmation and failure check |
|---|---|---|---|
| Project type: ecommerce | Allowlisted choice → `project_type = ecommerce` | New-business queue; coordinator assigned | Success: confirmation appears and the test record is assigned. Failure: show the agreed recovery route, log or retry according to the integration design, and verify the test record is reconciled. |
Design a visible and recoverable submission path
Explain what happens when the visitor submits the form, what confirmation they will see and which route to use if they do not receive it. On the staff side, define an owner or queue, a duplicate-handling rule and a way to identify submissions that failed to reach the CRM.
Protect the form endpoint against abuse using controls appropriate to the implementation, while keeping error messages useful to actual people. Avoid returning internal CRM errors or personal data to the browser. Decide how attachments are handled before enabling uploads.
Test both normal and failure cases
Use synthetic test records to check required fields, invalid values, spam handling, CRM mapping, assignment, email acknowledgement and analytics events. Then make the CRM unavailable or simulate a rejected request in a safe environment and confirm how the submission is logged or retried.
If you rely on a provider's tracking script to capture an external form, check that provider's limits. HubSpot says its non-HubSpot form capture depends on its tracking code loading; external validation can also create partial submissions. Those are HubSpot-specific behaviours, so test the exact form, browser and integration you plan to use rather than assuming another connector works the same way.
Do not use actual customer data in a test when synthetic data will demonstrate the route. Confirm which team can see test submissions and how they are removed after the check.
Agree ownership before launch
Name one owner for form copy, one for CRM fields and one for operational follow-up. Record who can change routing rules and how the team is told when a field or sales process changes.
After launch, inspect a small number of synthetic or appropriately authorised submissions end to end. A successful browser confirmation does not by itself prove the lead arrived in the right CRM queue or that the organisation's privacy obligations have been met.