Why Website Enquiries Aren't Reaching Your CRM
If website enquiries are missing from your CRM, trace one test submission from the form to the person who should receive it.
The enquiry may have failed validation, stopped during delivery or arrived in a queue nobody checks. Start at the last step you can confirm.
Identify the connection
Find out whether the site uses:
- A form embedded from the CRM.
- A website form connected through a plugin.
- A custom integration using the CRM's API.
An embedded form may submit directly to the provider. A custom integration may store the enquiry on the website before sending it. Check which system holds the submission and where delivery errors are recorded.
For example:
Form submitted → request accepted → delivery attempted → CRM record created → team assigned.
Use the CRM worksheet to record the stages in your setup.
Send a recognisable test enquiry
Use fictional contact details and an agreed test reference. Record the time, form URL and expected destination.
Check the browser response, then the submission and delivery logs. If the request has an identifier, use it to follow the enquiry through each stage.
A confirmation email may come from a separate process, so check the CRM record itself.
Check the fields being sent
Read the receiving system's error response. Common problems include:
| Check | Possible cause |
|---|---|
| Required fields | The CRM now requires a business unit that the form omits |
| Dropdown values | The form sends a retired service category |
| Field types | Text is sent to a date or number field |
| Length limits | The message exceeds the receiving field's limit |
| Record references | The assigned owner or related account no longer exists |
| Environment | The form still points to a test CRM |
Record the error and relevant field without copying customers' messages into general-purpose logs.
Check access and temporary failures
Confirm the account, credentials, permissions and endpoint. An account may authenticate but lack permission to create the required record.
Read the status and headers as well as the response body. In a custom Dataverse integration, a successful create request can return 204 No Content, with the new record's address in OData-EntityId. Code that expects a JSON body could wrongly report that as a failure. Requesting Prefer: return=representation returns the created data with a 201 response. Microsoft documents both responses.
For Dataverse service-protection errors, 429 Too Many Requests includes a Retry-After value in seconds. Repeated immediate retries can extend the wait. Follow the server's retry guidance.
| Evidence | Next check |
|---|---|
| Successful create response with a record identifier | Find that record; check ownership and staff filters |
| Rejected field or required value | Correct the mapping before retrying |
429 with Retry-After |
Wait for the indicated delay |
| Timeout with no confirmed result | Check whether the record exists before replaying |
Avoid duplicate enquiries during retries
After a timeout, the website may be uncertain whether the CRM accepted the request.
Give each submission a stable identifier across delivery attempts. Use the CRM's supported method to prevent the same submission being created twice.
Email address alone is usually insufficient: the same person may make several legitimate enquiries. Keep retries limited, alert someone when they are exhausted and provide a way to resend failed submissions.
Keep a contact identifier and an enquiry identifier separately. A contact can exist already while a new enquiry still needs its own record. Otherwise a “duplicate contact” decision can accidentally discard a different request from the same person.
Check who can see the record
Once the CRM accepts the enquiry, inspect its owner, queue, status, region and service.
Search for it using an authorised account. Check saved filters and staff notifications separately. A record assigned to an inactive owner can look like a delivery failure to the sales team.
For WorkUP Queensland, we embedded Microsoft Dynamics forms into the website. With this type of setup, the CRM provider's submission records are a useful place to start tracing an enquiry.
Retest after the fix
Repeat the complete submission and confirm that the intended team can act on it.
Monitor waiting deliveries and unresolved failures. Assign someone to respond when an alert fires, and repeat the check after changes to forms, CRM fields, credentials or plugins.
Our business software integration service can help diagnose and repair the connection.