i was recently trying to connect a website contact form with SuiteCRM so that whenever someone submits the form a lead gets created automatically in the crm. initially tried a small custom api script but it quickly becomes messy when you have to deal with field mapping and multiple forms across sites.
for a few wordpress sites i ended up using a plugin called Contact Form to API which basically sends the form data directly to the crm api and creates the lead. setup was fairly simple once the endpoint and fields were mapped.
just wondering how others here are handling this kind of integration. are you mostly writing custom middleware or using some other connector for sending form data into suitecrm?
curious if there are other similar approaches people are using.
There is the Web2Person form that you can simply generate from SuiteCRM:
The advantages here are:
Very easy to setup
Then, I’ve got all thinkable other constellations as well, sorted by frequency in projects:
Forms to API request
Similar to what you’ve mentioned as well. There is a form builder out there, could be anything from WordPress / Drupal Webforms / Zoho Forms / Google Forms / perspective / form io / n8n Forms / ActivePieces Forms - anything what the marketing (sales / customer service / aftersales / project) department has in place already.
Those are then configured to send an API POST request.
I usually have a middleware like n8n / ActivePieces in place.
This is then handling some logic (duplicate check, attaching to existing opportunities / projects or similar).
Seldom I’d send from the form directly to Suite. If so, I’d usually do it via a custom module and build the logic inside the SuiteCRM workflow.
Advantages:
Duplicate / spam handling / further logic
All sorts of enrichment possible
Mautic forms
The “best” approach (depending on the requirements of course) is usually via Mautic.
One would build landing pages including forms in Mautic and then the data is being sent directly to SuiteCRM with the appropriate matching / duplicate handling etc.
That works with a custom middleware as well - the standard Mautic plugin to connect the two systems doesn’t fulfill most standard requirements in marketing and sales departments.
I’m working on a turnkey solution there:
Advantages:
Builds on the existing Mautic setup and performs nicely in marketing
Integrates directly with SuiteCRM and all down-stream processes
Forms to middleware in DMZ
Similar to forms to API middleware. That special approach is required when customers have their CRM in a private network / behind a VPN and data should still come in from the internet.
Here, I’ve developed some custom solutions to receive the request, do some validation / transformation and forward the payload to the CRM.
I’ve found the best solution for WP → SuiteCRM is Gravity Forms and the Webhooks plugin. It does take a bit of code to format the submission the way SuiteCRM likes it, but you allow the user more or less to be able to add/change fields without having to get a developer involved. Gravity Forms is a rich form builder with tons of features and also alot of developer features. You can pretty much do anyting with GF + Webhooks to SuiteCRM.
The Uncanny Automator can do the posting to suite (it takes two actions to get the API access_token and then send the data), it has many form plugin integrations (we use forminator and it has the ability to listen to forms from forminator). This is all on the free version of Uncanny Automator as well.
I have used this, N8N (with Forminators inbuilt Webhook plugin) and custom code in some instances as well.
I usually prefer a middleware layer instead of sending form data straight into SuiteCRM. It can validate required fields, normalize phone numbers, check duplicates, refresh API tokens, and log failed requests for retry. That keeps changes in the website form from breaking the CRM, and it’s easier to support when several sites are involved.
Once the lead is created, an automated, permission-based SMS or voicemail follow-up can be useful, especially for missed inquiries. Drop Copwoy is one option I’ve looked at for coordinating those messages, but I’d still make consent, opt-outs, and CRM status checks part of the workflow.
Late to this, but here is what we ended up with on a small non-profit setup, because the failure modes matter more than the plugin choice.
We take enquiries from a WordPress site (ninarkotikam.com, a rehabilitation centre) and from a Telegram bot. Everything goes to SuiteCRM as a Lead. Three things bit us, in this order.
Lost submissions. Posting straight from the form to the CRM API means that when the CRM is down or slow, the enquiry is lost and nobody notices. For us those enquiries are people calling for help at 2 a.m., so losing one is not acceptable. We now write the submission to our own table first, answer the visitor immediately, and push to SuiteCRM from a queue with retries. The plugin approach is fine as long as there is a fallback store behind it.
Field mapping drift. Somebody adds a field to the form, nobody updates the map, and the data lands in description as free text. We keep the mapping in one config file and log a warning when an incoming key is not in it. That one warning has saved more data than any validation rule.
Duplicates. The same person submits twice or writes from two channels. Web2Lead does not deduplicate. We match on phone first, then email, and only then create a new Lead, otherwise we append to the existing one. Without this the pipeline looks great and the intake people stop trusting it in a month.
On the connector itself: Web2Lead is enough if you have one form and no custom fields. Once you have several sources, a thin middleware that owns retries, mapping and dedup is less work than maintaining three plugins. Ours is about 200 lines of PHP.
One extra thing for anyone in a similar field: record the source (form, phone, messenger) as a proper field, not in the notes. It is the only way to see later which channel actually brings people who follow through.
If your instance is down or slow, that’s not a form issue, thats a resources/setup issue. You need to address that first.
The advantage of Gravity Forms is two fold. 1) spam protecttion and 2) it keeps a record of each submission. As a side benefit it also keeps record of the webhook and response to help you troubleshoot your SuiteCRM API issues.
I also developed my own anti spam add on for Gravity Forms that substantially reduces bot spam. (almost zero but its like an arms race, I keep having to add new screening methods).
This setup is rock solid and I never lose a lead.
Regarding fields, etc. This is a question of access control and responsibility, not necessiarily design.
If everyone has access to Studio and is randomly adding fields, you have no control. This needs to be limited to admins and you need a documented process for adding new fields, like :
Check/Test web forms.
Ensure field is created in leads/contacts/accounts as appropriate so if follows on conversion.
Users are notified of new field and it’s proper use
etc.
This is what works for me and this is what I setup for my clients as well.
@pstevens I always find that accounting for unavailability of the service endpoint (ie Suite) is always a good thing to do (all sorts of things can happen that block access to a remote API not just the Suite service being down or slow). In this instance I would be making the push from Wordpress/Form to Suite happen via cron (ie the submit of the form creates a cron task that pushes and retries if it fails), this also has the benefit of pushing the entire connect to an external service into cron, therefore speeding up the live form submit.
