With this release, Eloqua is discouraging new instances from enabling the “legacy” integration. So, if you create a new instance of Eloqua from here on out and need to integrate it with SFDC, you must use this app.
My colleague Bray Coleman wrote about this app back when it was under controlled availability. Since then, a lot of little changes have happened within the app and will continue to do so, especially in the upcoming 19C Update.
I had the opportunity recently to really dive deep into this app with a client who needed me to setup their new Eloqua instance and connect it to their existing SFDC, and I found a few major differences:
- You must use Program Canvas instead of Program Builder
You now have to build all of your rules and logic within Program Canvas instead of the slower Program Builder. Fortunately, there are several advantages of using Program Canvas.
The main advantage program canvases have over program builders is that contacts can reenter and flow through programs almost instantly. As a result, you can now create leads and update contacts from Eloqua to Salesforce in five minutes or less. This provides fast validation of your logic so that you can quickly react to errors and make changes on the fly.
Program canvases also provide the powerful listener step, which you can use to bring in contacts from other programs, form submissions, lead scoring changes, contact creation, and contacts that have had a modified value in one of up to ten tracked fields (also a new feature of the 19B Update). Additionally, you can configure the new listener step to pull in contacts from an Import. You can also configure two “add” type steps that will either send the contact through an action or a campaign response action.
These are the three new steps available on the canvas when you install the app.
- New names, new and improved functionality
Before I get any further into the design changes, let us compare the semantic differences so that users familiar with the legacy integration can become familiarized with the new app:
- The design pattern has changed
Now that we have an understanding of the alternatives names and functionality introduced within the new app, let’s take a look at the change in design pattern as a result of using only program canvases with these app steps.
At a minimum, you can create a Program Canvas with your outbound logic — typically of the “create lead, update lead, and update contact” trifecta (aka Create Unique or Point of Interest) — and call it a day — without ever touching Program Builder and without having to wait at least five minutes in priority mode to see the results of the external call. This accelerates processing speed for both inbound and outbound contacts, and better supports GDPR and CCPA requirements such as advanced logic and enhanced subscription management.
Other common features in the integration process include:
- Data normalization
- Data appendage
- Lead to account matching
- Marketing status evaluation
- Territory/sales rep assignment
The details for each of these subprocesses are custom and depend heavily upon existing SFDC configurations and primary business processes. Because many of these particulars will widely vary, I recommend abstracting them and placing each of these subprocesses into their own Program Canvas, assuming that each of the program canvases will have a listener for input and a “move to program” step for output. This abstraction of the processes gives us the ultimate flexibility in regards to order of execution, maintenance, error handling, and scalability.
Given that these routines live in their own independent programs, we can construct a single program (I call it “Grand Central”) that manages the flow of contacts to and from each of these programs. This program can also take new or existing contacts with specific changes, run them through the existing processes, and then send them outbound to the SFDC integration.
Next, I have a set of programs that manage inbound contacts and tag them specifically by source. For example, I have programs that track list uploads, field changes, new SFDC leads, new SFDC contacts, and other sources (e.g., manual creation or third-party integrations such as social media), and each of these programs feed into Grand Central. From there, Grand Central takes the contact through the other subprocesses and then sends them outbound back to the integration.
This is an example of how you can build a design pattern (i.e. Grand Central)
that manages data flow from inbound to outbound programs.
- Associating contacts to campaigns
Now, you may ask, “But, what about campaigns and associating contacts to campaigns?” This is a valid concern, but the new documentation for this app does not include those steps and they are not provided as defaults. So, what gives?
You have three options:
- Go the traditional route: Create the Associate leads/contacts to campaigns actions, place them in your outbound program, and ensure that the Eloqua contact has that field written to appropriately.
- Use the SFDC Campaign Association app: Yes, this is a separate app, but it allows you to place a step on each individual campaign canvas and associate the contact to a specific SFDC campaign and status.
- Use the Response Rules in conjunction with the Campaign Response Integration: Many users have had the response rules module for years, but few seem to use it. I recommend setting some default actions to associate and set a status to a campaign. I also recommend using a single, separate Program Canvas that captures the campaign responses (either through a listener step or segment) and sends that to the SFDC Campaign Response Action. Ideally, you can use this in parallel with the SFDC Campaign Association app when appropriate.
The best way to get to know the new Salesforce.com Integration app is to dive right in. As Bray recommended in his blog post, I also recommend first testing the new app in your sandbox, if possible, before moving into production. Or, you can reach out to one of our friendly DemandGen consultants to help you get up and running quickly.
Devon Guerrero is a Solutions Architect for DemandGen and a certified Eloqua Implementation Specialist. In addition to putting together creative solutions for his clients, he has a long-term goal he practices and preaches: to unite the two distant worlds of marketing and engineering by creating the “marketing engineer.”