WordPress forms into Dynamics, without a plugin that almost fits

The water-treatment company runs its sales and maintenance operation in Microsoft Dynamics, and website enquiries, contact details and form data had to arrive there automatically. We built the WordPress site and an integration layer with mapping, validation and retry on failure.

A form-to-CRM plugin is a good choice for simple cases. These are the usual signs you have outgrown one:

• Different forms need to create different kinds of record, or reach different teams.
• You need to check for an existing customer before creating a new one.
• A field has to be transformed or looked up, not only copied.
• Nobody can say what happens to a submission when Dynamics is down.

Save every submission in WordPress before you try to send it. A form that calls Dynamics directly, and shows an error or loses the data when that call fails, is the most common fault in this kind of work. Once saved, the visitor gets a thank-you straight away, and sending happens separately. Spam filtering runs at this step too, so junk doesn’t land in your CRM.

This is a typical mapping into Dynamics 365 Sales, whose tables are in Dataverse. Your configuration will decide the details, and Business Central has a simpler model built around customers and contacts.

Dynamics will reject what it can’t accept, and often with a message only a developer can read. Check it first: required fields, length limits, valid choice values, email format, country codes. Anything that fails goes to a person with a readable reason, and the enquiry stays visible. A sales lead must never vanish because a phone number had a letter in it.

On Dataverse, upsert with an alternate key lets you create or update by your own identifier. A resend then updates the same record rather than creating a second lead. The Web API authenticates with an application user through Microsoft Entra ID, so create a dedicated one with only the permissions it needs, and keep credentials out of the WordPress database if you can.

• A timeout, 5xx or a 429 with Retry-After goes back in the queue, with a growing delay.
• A rejection caused by the data goes straight to a person, because retrying won’t help.
• After a set number of attempts, someone is emailed the enquiry itself, so it can still be answered today.

WP-Cron depends on site visits by default, so a quiet site can delay retries for hours. Run it from a real server cron.

Forms get edited, Dynamics fields get made mandatory, and credentials expire. Any of these can stop delivery while the website looks fine. Two small things catch nearly all of it: a daily count comparing submissions with records created, and an alert when anything has waited too long. If you plan to run without an ongoing support contract, as on this project, make sure someone on your side receives those alerts and knows what they mean.

Orders and invoices are a bigger project with different risks. See the field mapping guide and how to choose between plugin, connector and custom. For the website itself, see WordPress development, or our integration service for the connection.