Use the built-in workspace first
Captured enquiries can be reviewed as lead records alongside conversation context. Staff can manage follow-up information such as status, notes, and tasks through the business workflow. Decide who reviews the new lead list and which action should follow each type of enquiry.
A record in the workspace is not automatically a record in an external CRM. If your team already uses another system, define which system owns the contact and the follow-up status before building a connection. Duplicating data without an agreed process can create conflicting records.
Define an event and a field mapping
Choose the event that should trigger delivery, then list only the fields the receiver needs. A new enquiry may need a contact method and requirement, not a full transcript. A status update may need an identifier and status rather than another complete contact copy.
Use synthetic data in the first test. Confirm how the receiving system handles missing fields, repeated requests, and different phone formats. Record a stable event or lead identifier so retries do not silently create multiple contacts.
Verify signed delivery at the receiver
The application webhook delivery signs a timestamp and request body using an HMAC secret. A secure receiver should verify the signature against the received body, check the timestamp according to its replay policy, and handle duplicate event identifiers. Keep the shared secret server-side.
A successful HTTP response alone does not prove the business record was mapped correctly. Review the destination record and receiving logs. Delivery errors, retries, and queue configuration require an operator to maintain the workflow.
Native connector availability
HubSpot, Zoho CRM, and Google Sheets native setup is [CONFIRM WITH OWNER]. This page does not publish one-click sign-in, a certified marketplace connector, or an included mapping wizard for those tools. A developer may be able to build a connection, but that is a separate implementation.
Ask about access conditions, cost, event coverage, credentials, and support responsibility before committing to a connection. Website widget embedding and external CRM integration solve different problems; installing the snippet does not grant access to a CRM account.
Connection acceptance checklist
- The required event is emitted in the tested workflow.
- The receiver verifies the signature and rejects invalid requests.
- Only approved fields are delivered and mapped correctly.
- Retries do not create duplicate destination records.
- An authorised person can investigate delivery failures.
Keep privacy and deletion consistent
Review permissions and retention in both systems. If a person requests deletion or correction, a copied record may need attention at the destination as well as the LeadVaani workspace. Optional browser analytics deletion does not manage external CRM contacts.
Avoid publishing secrets or using private chat content as a debugging screenshot. Give the developer enough synthetic examples to test mapping without real customer information. A smaller connection with clear ownership is easier to maintain than transferring every available field.
Test failure and repeat delivery before using real data
A connection should be tested with a rejected signature, a repeated event, and a temporary destination failure, not only a single successful request. Review how the receiver logs each case and whether staff can tell which record needs attention. Use synthetic contact details while validating these behaviours.
Agree on responsibility for failures with the receiving-system administrator. If a destination rejects a field, decide whether to correct the mapping, retry, or request staff review. A queue that repeatedly retries an invalid record will not fix the underlying business rule.
Document the approved field mapping and where the secret is configured. Give only authorised people access to delivery logs that may contain customer information. Recheck the connection when a CRM field, endpoint, or permission changes. The built-in workspace can remain useful even when an external connection is unavailable; keep the staff follow-up process clear in that situation.
A controlled trial to adapt
Example to adapt: deliver a synthetic lead event twice to a test receiver and review whether one intended destination record remains. Then send a request with an invalid signature and verify rejection at the receiver. Ask the developer to explain how a failed mapping is surfaced and who can act on it. Keep private secrets and real customer data out of the test report. These acceptance checks help evaluate a custom connection, but they do not establish native connector availability or a contractual delivery guarantee.