A website's role is to promote your brand and gather leads! The leads are typically sent from a web form to a CRM (eg. Salesforce or Microsoft Dynamics) or a marketing automation system (e.g. Salesforce Marketing Cloud or Pardot).

This article looks at the importance of the lead creation process in the context of Sitecore forms. It is important that implementers understand the complexities that lie ahead when they adopt a particular approach.

The Objectives

It is well understood that lead response times have a direct relationship to sales success. Clearly, a lead will look elsewhere if your company is unresponsive so actioning leads quickly is important. It's not the only requirement of lead creation:

• Easy set up: Web form creation must be fast and not require development expertise  
• Flexible: Forms can be mapped to one or more destination objects and, if any, their related objects
• Effective: Duplicates should not be created and good data should not be overwritten by bad
• Understanding: Forms know about the remote system e.g. aware of lead conversion
• Efficient: Transactions happen quickly and don't create excessive API calls to the remote system 
• Scalable: If a social media campaign goes viral, the form should handle the increase in traffic
• Graceful in failure: If something goes wrong the lead details must not be lost
• Extensible: In complex situations, out-of-the-box features can be extended to fulfill requirements

Now, this is a lot to ask of any form so we will need a transaction technology that meets these demands.  Essentially this is deciding to sync, transact in real-time, or a combination of both.

The Challenges of Meshing Data Schemas

Transacting by Syncing

This approach, favored by Sitecore's Data Exchange Framework, regularly fires a batch process to replicate data in a Sitecore database e.g xDB, to a remote system, or vice versa. The challenges with this are: 

• It is not possible to pre-test object fields in the remote system before updating them
• Syncing cannot implement complex, granular, or related list transactions
• Syncing uses the Last Modified Date so updating irrelevant fields in either system forces the record to sync. For example, adding a custom field to a CRM record changes the Last modified Date for every record thereby forcing an unnecessary sync 
• Syncing cannot deal with multiple objects e.g. more than one Sitecore goal cannot be synced (the mapped receiver field will be overwritten multiple times) 
• Syncing cannot handle CRM lead conversion i.e. if a lead has been converted to a contact, a sync will cause a new lead to be created
• Significant updates create intensive activity in xDB - 100% CPU usage that can cause a sync failure
• Delays occur before the data appears in the destination system
• Between sync processes, the data is in an unknown state. If field values have been updated in the remote system syncing can overwrite good data with bad
• Data is replicated in both systems requiring additional storage
• The event that initiates the sync is within Sitecore (usually a scheduled task or button click)  

One advantage that syncing has is the data is always local, eliminating the time required to fetch it from a remote system.

Transacting in Real-Time

The objective of this approach is to create a single source of truth that supplies data to any system that needs it e.g. a CRM or marketing automation system. Transacting in real-time has fewer challenges:

• Transactions are slightly delayed while data is being retrieved from the remote system
• Solutions tend to be purpose-built for the remote system

Transacting in real-time solves all the issues of syncing and is ideal in the following situations:

• If the data flow is complex e.g.
  • Object fields need to be pre-tested before being updated
  • More than one related object needs to be created or updated
  • Irregular numbers of items in one system need to be available in the other
  • Multiple languages are being used
• Sitecore xDB analytics are being pushed to the remote system
  • This data is complex with multiple objects, some with dependencies on each other
• Where data quality is paramount
  • You need to know the data you are looking at is 100% accurate
  • You need to know immediately when a web form has been submitted
  • You need to ensure duplicates are never created  
• CRM lead conversion is used 
• Sitecore xDB cannot be isolated to its own server (if website volumes are high)

Conclusion

Sitecore forms integration can be a minefield for the uninitiated. On the surface, it looks like pushing a few fields to a remote system but a number of surprises lay in wait - ask any Sitecore partner who has completed an integration. And we have not even talked about Sitecore CDP ...

When mapping Sitecore forms to an external system, many challenges can be overcome by transacting in real-time. When building or purchasing an existing integration you need to consider the complexity of the data and how it will fit into the remote schema.

FuseIT specializes in Sitecore to CRM integration. Our enterprise S4S and S4D integrations enable the real-time exchange of data between Sitecore and Salesforce and Sitecore and Microsoft Dynamics 365. Please contact us for more information or to see a demo of these in action.