Sending Sitecore web form submissions to Salesforce is a primary business objective if you use Sitecore and Salesforce. This critical process must be flexible, scalable, easy to configure, and graceful in failure.
FuseIT's S4S has been mapping Sitecore forms to Salesforce for over 12 years. Over that time the mapping wizard has been continuously improved. However, recent trends towards more complex forms and the use of staging objects in Salesforce have driven us to create an entirely new wizard. The new S4S Save to Salesforce Mapping Wizard is more flexible than the original S4S Form Mapping Wizard. S4S for Sitecore versions 10.2 and above will include both wizards so customers can choose which one best suits their needs.
First and foremost the S4S Save to Salesforce Mapping Wizard accommodates a plethora of push-to Salesforce scenarios e.g. populating staging objects, handling lead conversion, testing fields before overwriting, identifying duplicates, and many more. The way to meet these needs is to move away from blind syncing - a process that updates an endpoint without rhyme or reason. The new mapping wizard transacts in real-time which makes almost anything possible.
Unlike the S4S Form Mapping Wizard, the new wizard connects to web form submit actions rather than the Sitecore form itself. This enables multiple form submit actions to be connected together by workflow. Out-of-the-box, the wizard is actually two wizards, each associated with its own submit action.
- S4S Save to Salesforce Submit Action transacts data between the web form and Salesforce
- S4S Identify Sitecore Contact Submit Action transacts data between the Sitecore web form and xDB
S4S Save to Salesforce Submit Action
This submit action transacts data between the Sitecore web form and selected objects in Salesforce.
Again, the wizard pops up when the Submit Action is added to a form.
Salesforce connection details
Companies often have more than one Salesforce instance so the wizard can select which instance the form should be mapped to and which object.
If a lead or contact is selected, an object owner can be chosen. This allows a licensed user in Salesforce to be configured to receive a notification if a visitor completes a web form.
Mapping form fields to Salesforce
This allows the nominated Salesforce object to be created or updated when the form is submitted. An update will occur if a form field with a Matching rule has a value that matches a value in the chosen Salesforce object. Multiple key fields can be selected for matching e.g. email address and first name.
Note that a Sitecore form field can be mapped to more than one Salesforce field. This helps keep key data in Salesforce from being accidentally overwritten.
Using the Do not overwrite check box, a Sitecore form field can be configured to not overwrite the mapped Salesforce field value unless it is empty. This helps protect important data in Salesforce.
The Save file uploads as attachments checkbox will appear if the form has file upload fields. If checked, the files will be uploaded to an attachment in Salesforce. A good example is attaching a resume (CV) to an online job application. The submit action may push the uploaded document to Salesforce where it appears as an attachment to a lead.
Sending Sitecore visitor behavior to Salesforce
Sitecore tracks the browsing behavior of each visitor and this analytics data can be made visible in their Salesforce lead or contact record. This happens when the form is initially submitted. To ensure the data in Salesforce is updated if the visitor returns to the website at a later date, there are two options:
- Use the Get Analytics button on the Salesforce lead or contact record to update the analytics data for that record only and/or
- Configure the Sitecore scheduler to use S4S to regularly push all the behavior from recent visits to Salesforce. The systems are synced (keyed) based on the Sitecore AliasId that is sent to Salesforce with the analytics.
The Push Sitecore Analytics checkbox enables the analytics to be pushed to Salesforce when the form is submitted. If checked, you may also set Sitecore personal information and email facets into xDB from the form values. This mapping is replicated in the S4S Identify Sitecore Contact Submit Action to enable the submit actions to be used independently.
Submit actions can be chained together so that a single form can insert or update multiple objects in Salesforce that reference each other e.g. in a parent-child relationship. Each action would point to a different endpoint object. Linking objects requires the Id of the first Salesforce object to be known to the second and so on.
After a submit action creates or updates the first Salesforce object, the object's id can be saved in a hidden form field. This makes it available for use by subsequent submit actions (on the same form) where it can be mapped to a related object.
The following are examples of what can be achieved:
"Only create a task if a lead can be created or updated."
This requires two submit actions, one to create or update a lead and another to create a task. The Conditions section of the first submit action (see above) requires a LeadId from Salesforce before a task is created or updated by the second submit action.
"Map to a different Salesforce object if a form field matches a preset value."
Again, this requires two submit actions. In the first submit action, if a form field value matches a preset value, Object 1 will be created in Salesforce then the second submit action will be executed. If the same form field value does not match the preset value, then Object 2 will be created in Salesforce.
Another useful feature is automatically collecting all the visitors who submit a web form in a Salesforce campaign. If the form is mapped to Salesforce leads and contacts, the submitter is enrolled in the campaign or campaigns nominated in the Map to Salesforce Campaigns field.
Finally, the Abort form submission if Save to Salesforce fails check box will not submit the form to Salesforce if the form processing fails. If you are wondering why a web form submission would fail, picture an excavator digging near your data center. It is possible for visitors to access the website even if the connection between the site and Salesforce is down. This scenario does not cause the loss of form data being submitted to Salesforce. If the submit action detects a connection loss, it can be configured to send an administrator an email containing the form field names and field values. This data can also be captured in Sitecore or in a dedicated database.
One or more conditions can be applied to determine if the submit action will send information to Salesforce.
If the conditions are not met, the submit action will do nothing and could potentially skip to the next submit action that will update a different object in Salesforce.
Handling converted leads
In Salesforce leads can be converted to contacts during the qualification process. During conversion, the lead field values get mapped to their equivalent contact fields. The submit action automatically recognizes when an existing lead has been converted and attempts to update the same fields on the contact instead. If a field with the same name does not exist in the contact entity, the field cannot be updated.
Submit to multiple Salesforce instance
By using more than one submit action it is possible to push form information to multiple Salesforce orgs or to a specific org. Again, the conditional logic can be used to compare the values in a form field against preset values to determine if the first action should be executed or skipped. The second action is configured to do the opposite.
S4S Identify Sitecore Contact Submit Action
This Submit Action saves and reads xDB visitor identification data. It is only required for customers who have needs that cannot be served by the standard submit action(s) but still want to implement analytics.
The associated wizard pops up when the Submit Action is added to a form:
The wizard and submit action have three features.
Select the identifier
When a visitor completes a Sitecore web form, there is often a need to store a form field as an identifier value in the visitor's Sitecore xDB contact record. The usual identifier is an email address but it could be any other form field. Once captured in xDB, the identifier can be used in future visits e.g. identifying a visitor who arrives via an email clickthrough. Leaving the selection blank will use the field name that has been configured in the S4SAnalytics.config file.
Select the field to store the AliasId
The second function is to populate a web form field (usually hidden) with the Sitecore AliasId. If a prospect visits the website on several occasions using different devices e.g. a desktop browser and a smartphone, Sitecore tries to determine if they are the same person. If it identifies them as the same visitor, the AliasId of the first visit is assigned to the second visit. By adding this value to a form field, it can be pushed to Salesforce on subsequent submit actions. Having the AliasId as a key field in Salesforce enables data, like Sitecore analytics, to be synced to Salesforce using a scheduled task.
Capture identifier form field values in xDB
The wizard has the option to save the form fields, email address, first name, and last name to the built-in Sitecore "Preferred Email" and "Personal Information" facets in xDB. This enables editors to use the facet data with Sitecore EXM and email marketing.
S4S has an API that enables Sitecore developers to easily exchange data with Salesforce in real-time. The APIs allow the creation of new functionality or the existing features to be extended. Both standard and custom Salesforce objects can be created, read, updated, and deleted using generic or strongly typed syntax.
FuseIT specializes in Sitecore to CRM integration. Our enterprise S4S integration enables the real-time exchange of data between Sitecore and Salesforce. Please contact us for more information or to see a demo of this in action.
* Friday in the US is
Saturday in New Zealand.