Integration patterns for connecting your website with your CRM

Previously we wrote about connecting your website with external systems, and specifically, the benefits of connecting your site with your CRM . As with many problems, there are many ways to approach this.

Over the years we've completed integrations with Salesforce, Microsoft Dynamics CRM, Goldmine CRM, SugarCRM, CiviCRM and even other, more esoteric systems. Different clients have different needs and different systems have different ways of doing things. Here are a few ways we've connected up sites with CRMs.

Note: I'm using the term 'integration patterns' to describe approaches we've successfully implemented in real life. You may have heard of the term 'design patterns', which are solutions to software design problems you find again and again in real-world application development. This is something similar.

All these examples come from real life, but whilst an example might refer to a particular CRM, e.g. Salesforce, it could be just as applicable to another system, e.g. Dynamics.

Example Integration Patterns

Website Lead Generation

(example using Salesforce)

With this pattern, the website acts as a data capture mechanism, generating leads for Salesforce. When a user submits a form on the website, the data is instantly sent to Salesforce and a 'lead' object is created. This is known as 'web-to-lead'.

• Communication is one way: web -> Salesforce
• Whilst data comes from the web, once it hits Salesforce, Salesforce becomes the canonical data source
• It is up to the Salesforce administrators to decide what to do with the data once a 'lead' is created. They may set up some sales automation business rules, or they may wish to have a human review each lead and decide the next step
• It uses Salesforce's REST API

This is one of the simplest integration patterns.

Member synchronisation

(example using Salesforce)

This is a pretty complex scenario. As with the last example, Salesforce remains the canon, as it is with Salesforce that the business users interact on a daily basis. However, in addition to capturing contact data on the website and sending it to Salesforce, members can log into the website and view and update their data.

• Communication is two-way
• Website captures information for new and existing contacts
• Upon update in Salesforce, contact data is sent to the website and member profiles are updated
• A unique identifier for the Salesforce record must exist in the website user profile
• A unique identifier for the user profile must exist in the Salesforce record
• We used Salesforce's SOAP API, but could now use their REST API as an alternative

Customer Contact Data Capture

(example using Microsoft Dynamics CRM)

This pattern captures data and uses it to create data objects, e.g. customers, purchases, etc in Dynamics.

• Communication is mostly one-way: web->CRM
• CRM becomes the canonical data source as it is used organisation-wide
• A middle layer sits between the CRM and the website, which takes submissions from the website and processes them into something Dynamics can use to create objects. This middle layer provides the API that the website can use.
• Where an object must reference another object, e.g. a purchase and a customer, the API layer can perform a lookup to get IDs of objects in CRM so that the new object can be created.

Web-based Contact Database

(example using Goldmine CRM)

In this pattern, Goldmine is the one true source of data, and the website publishes it in a user-consumable fashion.

In a perfect world, where Goldmine is accessible over the internet, Goldmine would expose its data at a URL. From this URL, Drupal would fetch the data, parse it, and create or update nodes as required for display. Mostly, however, Goldmine exists inside an office, and is not accessible. In such circumstances, the Goldmine pattern is as follows:

• Query the Goldmine database and produce a CSV file
• Upload that file to a specified location known to the website
• The website parses that CSV file and updates, creates or un-publishes its content as necessary
• Parsing a CSV file is relatively straightforward. The tricky part can be the automation of the data extraction from Goldmine and subsequent upload to the web server.

Customer Contact Data CRM

(example using CiviCRM)

CiviCRM does integrate tightly with Drupal, but sometimes using it to power the user facing elements of the website is not desired. In this case, CiviCRM provides its own API to allow Drupal's forms to insert data into CiviCRM itself. Extension modules for Drupal can also allow this.

Because of the very tight integration that already exists between the two systems (CiviCRM relies on the Drupal platform to work), getting data into CiviCRM is straightforward, and then the data can be viewed/manipulated with CiviCRM's own interface.

Customer data export

(example using 3rd party CRM application)

This is where a custom report is created to extract customer data from the website, in a specific defined format, such as CSV. This CSV file can be produced on demand. It can then be imported into the 3rd party application through its own import facility.

This is not a great way to connect the two applications as it involves manual steps and is difficult to automate, but it can be valuable when no other solutions are available, or as an interim measure until something more robust can be put in place.

Contact data exposed for interrogation

(example using 3rd party CRM application)

This pattern is similar to the data export above. In this pattern a custom database table is created and populated in addition to Drupal's normal tables. This custom table is configured to an exact specification, so that a custom query can take that data and feed it to a 3rd party CRM application.

The custom table is used as an interface: the CRM's query does not need to know anything about Drupal's internal structure, but yet is able to effectively pull data from the website as needed.

Built-in CRM

(example using RedHen)

Finally, here's a great alternative to connecting your website to a separate CRM, which is to actually build your CRM into your website. RedHen is a native Drupal CRM solution, fully utilising Drupal's power to be flexible, extensible and full-featured. Having your CRM built-in means that there are no network issues, no failed transactions, no lag and no wondering about whether that donation has made it through to the CRM yet. If it's on the website, it's already there, in the CRM.

--------

Have you proper integration with your CRM? If you'd like to accelerate your organisation's efficiencies and bring it to the next level, contact us.

Yes - I want to connect to my CRM!