Making a match: Salesforce and Emma

September 29, 2011 Alex Ezell

Salesforce is clearly a juggernaut. Businesses from the smallest retail bakery to Fortune 500 behemoths are using it to track customers, sales and a thousand other things. It’s long been a request from Emma’s customers to provide a simple two-way sync with Salesforce. And while we’ve been planning to build this integration for some time, it’s just recently that we’ve made major headway on this work.

Salesforce integration is one of the first major projects we’re building using our new API (outside of our own application, of course). Not one single piece of data is being moved from Emma to Salesforce or back that doesn’t use a call that’s publicly accessible via our new API. This is eating our own dog food in the same way building our application on top of our API is. We’ve learned a few things about our API and Salesforce so far, and I’d like to share the progress with you.

Salesforce is complicated

There are varying levels of features depending on what plan an organization uses. As such, there are limits and constraints at every turn regarding API usage, object and field access, user access and much more. It becomes a byzantine and grueling task to figure out not how but if you can do what the Salesforce documentation says you can do. That complexity also yields great power and flexibility; once you determine if you can do something, figuring out how is yet another challenge. It’s one model, but not one that Emma will likely mirror. Instead, we’ve opted for the “all you can eat” sort of model with our API. If you have an Emma account, then you can use any and all of the API.

Webhooks are easy

Webhooks, which we initially added as a bit of a fluke, are now the lynchpin of keeping the two systems synced. Anytime an event occurs — deleting a member, adding a member, sending a mailing, opening a mailing or clicking a link — webhooks are used to let Salesforce know that it should update its data. In this way, we don’t have to use a scheduled job or manual update process to get member data and response data into Salesforce in a timely manner. Webhooks have negated the need to build a middleware system that would have collected data from the two systems and then shuffled it around where it needed to be.

Documentation makes the medicine go down

The documentation largely works. We’ve uncovered a few inconsistencies here and there, but using Sphinx and a shared convention of docstrings for every public method has kept the documentation correct and comprehensive. By and large, the folks working on the Salesforce application have been able to use it to answer most of their questions about what the API can do. This is a significant discovery as we strive to make the documentation as clear and as helpful as possible. This is something we’ve come to appreciate about projects like Django and Flask, and while we might not emulate them exactly, we’re looking to share the same spirit. We have some work to do with regards to sample client code, more examples of typical workflows and what kinds of things might go wrong or be confusing. We are also working on ways to keep the published documentation more in sync with the auto-generated documentation.

Where’s the beef?

So, what are we building? If you’ve read this far, you’re probably interested to know what exactly our Salesforce integration will do.

Here’s a quick overview:

After installing the Emma application from the AppExchange, the user will provide their Emma API credentials and verify those details. To start, there will be a quick wizard type of process to perform an initial sync of the groups and members from Emma which you might wish to pull into Salesforce. You can also create new Emma groups using the results of reports you’ve generated in Salesforce. After that, any time you make updates in either system, those changes will be mirrored in the other system.

As for response data, the opens, clicks and shares that Emma tracks will be automatically updated in Salesforce for every member that has been synced with Emma. There are a few places it will be visible, but the most obvious will be in the Contact History section of each contact’s record. You’ll be able to use this Emma response data in reports and dashboards just as you would any other piece of data in Salesforce. We hope that after the initial sync and with the exception of creating new groups from reports, you won’t really have to worry about the Emma sync-up. You’ll just be able to use the response data generated by your Emma mailings and know that all your member data is synced between the systems. Like they say on those infomercials, “Set it and forget it.”

Previous Article
Using IIFEs in JavaScript to control variable scope

On a recent project, a few of us have been challenged to take our JavaScript skills to a new level. We’ve e...

Next Article
A sneak peek at an upcoming feature
A sneak peek at an upcoming feature

Re-structuring project teams As we prepare for a fall/winter release schedule that’s very ambitious, we’ve ...