The client manufactures and installs facade materials and elements: sidings, panels, tiles, shingles, and gutters. On their Drupal website, users can take a look at the products, request an estimate, request warranty service, or submit an issue. The visitors cannot make purchases on the website since the specifics of the goods require an individual approach and pre-taken measurements. But instead, there are a lot of forms here.
Key issues and tasks
Contents
After the user fills out a form, the data is transferred to the Drupal admin panel and, from there, to the Salesforce customer management system for further processing. Drupal can be integrated with Salesforce through the Salesforce Suite modules. With its help, the admin can log in to the service and use the API to work with Salesforce. The API supports both sending data from Drupal to Salesforce and importing Salesforce data into Drupal. However, we did not need the import option since the client did not plan to store Salesforce data on the website itself. They only needed to send data from certain fields of certain web forms.
Drupal has two roles on this project:
- receive data via contact forms;
- send data to Salesforce repeatedly or manually if the automatic data sending was interrupted by an error. This way, the user doesn’t have to enter this data again.
Salesforce Drupal integration
Drupal and Salesforce have different fields for storing data. We were to make them correspond, i.e., to configure field mapping. The Salesforce module has built-in standard mapping, but it wasn’t needed.
Drupal Hosting integration with Salesforce was part of legacy code that had been working on the website since its Drupal 7 days. The problem was that the way the forms worked was hard-coded. The code was stored in a Git repository, and the client could not reach it. The mapping for web forms was also hard-coded. As a result, there were endless pages of code defining what field corresponded to another field in dozens of forms. You had to dig into the code for every tiny problem.
All in all, our tasks boiled down to:
- creating functionality for mapping fields of Drupal and Salesforce web forms from the Drupal admin panel;
- configuring data resubmission to Salesforce in case of an error.
Solution
Field mapping
Since we don’t import anything from Salesforce, we set up a custom webform handler that runs immediately after submitting a completed form to generate an array of Drupal fields and send them to Salesforce. We list the fields that we plan to use in the handler itself.
Let’s look at this specific form.
In this form, you have to specify your order number, fill in the information about the problem and yourself, and leave your contact information. Once the Request Service button is clicked, all these fields are saved on the website; Drupal maps its fields to the fields in Salesforce and sends the data to the CRM. If an error occurs during sending, it is tracked and emailed to the client’s technical specialist.
Setting up field mapping
- In the build tab of the Drupal admin panel, we create and later edit fields for forms.
- Go to settings > emails/handlers and create a custom handler called salesforce mapping, which starts mapping after the form is submitted. In the editing mode of a mapping handler, there are general parameters that do not require mapping and special fields that require it. The site admin selects a form field from these drop-down menus and matches it with a Salesforce field. The list of fields is edited in the build tab.
- Hit save.
The principal member of this process is the PHP webform handler class. It specifies the fields, actions after submission, and the logic for sending data to Salesforce.
Resubmitting data to Salesforce
All submitted forms can be viewed on the Results page. But among, them there will be forms from which the data reached Salesforce and forms from which the data transfer was disrupted due to an internet outage, an outdated authorization token, or another issue.
The client values this data very much because it includes information about clients and complaints about product malfunctions. That’s why we created the Salesforce failed submissions page: only applications with errors are collected here. If some kind of server response is received, it will be mentioned in the error description.
Now the client can select one or several forms and re-submit them.
Work results
- Now there is no need to dig into the code: the client can add fields and configure mapping from the Drupal admin panel.
- Hundreds of lines describing the mapping and logic were removed from the code.
- It became possible to resubmit the form.
Work with the client continues.
A CASE STUDY ABOUT INTEGRATING SALESFORCE WITH WORDPRESS ➜
