Gathering Data From Public Web Forms

We have been working on a project that requires harvesting data from a public facing web form. This is a pretty basic request but in the past we’ve only been asked to do this for lead capture and we have generally specified using the C360 web capture tool as a very effective tool for capturing lead data and either relating it to an existing contact or lead or creating a new lead.

However with this project we have to capture data that updates an existing contact or creates a new contact (C360 currently doesn’t support this). We also have to create a custom entity using some of the captured data.

Our first thought was to build a custom web form using ASP.NET and have it connect to the target CRM system using web services. However, we were concerned about three things. First we could not always guarantee that our CRM server would be on line (even the best systems need patching etc.) , the number of hits/second at the public web form could be very high, perhaps higher than the target CRM system could process synchronously and provide a good user experience, and we had no guarantee that the public web server could support ASP.NET.

We decided to make a generic web capture system based on parsing email sent from a web form. Emailing web form data is a basic capability of most hosting platforms so this seemed to clear up compatibility issues. Email would also allow the process to be asynchronous so the users would not perceive a delay. Additionally, email would allow the process to survive a short CRM server outage.

The process is pretty simple. We created a service that monitors a specified CRM email enabled queue. When an email arrives in the queue, the service reads it, parses it, and used the data to create a web request record in CRM (a new custom entity). For auditing purposes we also attach the inbound email the the newly created web request record.

When the web request record is created a workflow rule executes that calls a custom .NET assembly to search for a matching contact record (we use email address just like C360 does) and then either relates the web request to the contact or creates a new contact and relates the web request to the contact. After relating the contact to the web request it is very easy to use the existing workflow functions for dynamic updating to update the contact fields that we want to update. We create and update the custom entity using a similar process.


3 thoughts on “Gathering Data From Public Web Forms

  1. ? Sounds over complicated to me!
    Why didn’t you write the web response to a MSMQ then write a service to pick up the details from the key to process into CRM?

  2. MSMQ is great but email is more flexible. We don’t always have control over the web sites where forms are posted but emailing form results is generally available.

Leave a Reply

Your email address will not be published. Required fields are marked *