How NavMantra connected its website audit form to Twenty CRM.

The operating requirement

NavMantra needed one public entry point for workflow-audit enquiries. A successful submission had to create a usable CRM person, opportunity, and follow-up task without adding a second lead database to the website.

The implemented path

1. 01

   Native website form

   The visitor provides business contact details, one workflow focus, a brief, and explicit permission to be contacted.

2. 02

   Cloudflare validation

   The server validates field limits, source, consent, honeypot, submission identifier, and Turnstile before contacting the CRM.

3. 03

   Isolated CRM write

   The server fixes the destination to NavMantra’s Twenty workspace; the browser cannot select another brand or provide credentials.

4. 04

   Retry-safe completion

   A stable submission identifier prevents retries from creating duplicate opportunities or tasks, and the interface shows success only after the required CRM writes complete.

Privacy and ownership rules

• No form PII is intentionally emitted in application logs.
• No website lead database or cross-brand customer table is introduced.
• The intake credential is server-side and workspace-specific.
• The request is contact permission for that enquiry, not marketing-list consent.
• Brand applications remain authoritative for their own bookings, payments, consent, and fulfilment.

What this evidence demonstrates

This is evidence of NavMantra’s own operating implementation, not a customer case study or a claim about commercial results. It demonstrates a practical pattern: define ownership first, constrain routing server-side, make retries safe, and prove the complete handoff before reporting success.