The 6 Core Components of Your Next Integration

Matt Chinnock
Valence
Published in
4 min readMay 24, 2017

Whether you’re connecting your Oracle Database to Salesforce as part of a year-long data remodeling project, or linking your blog to your Mailchimp account over the weekend, what you really care about is getting your beloved data from point A to point B swiftly, securely, and in one piece. But have you thought about the tools you need to achieve those goals?

Today we’ll take a look at six critical features to think about when moving data across systems.

Data Mapping

When you distill integration down to a basic level, you think of data mapping; linking Field A in your first system to Field B in your second. Getting your hands on an integration tool is a bit like giving a kid the keys to a candy store; you’re going to want everything. Consider the business need behind every mapping and avoid moving data just because you can. It’s better to have a concise collection of data in your primary system than to overwhelm your team with a plethora of fields. Map the data that gives each user role the most business value, and nothing more.

Data Filters

Sometimes your mappings alone aren’t enough to get exactly the data you want, and nothing else. Lets say mappings are in place to transfer all company Accounts into Salesforce, but Acme Corporation fall outside of your Sales team’s regional jurisdiction (sorry, Bugs). Filters can be applied to remove all Accounts with the name “Acme”, so that Acme Account data never makes it into Salesforce at all. Remember that the goal as a Systems Integrator is to end up with relevant data, and only relevant data.

Data Transformation

In certain circumstances you may need data from an external system that uses a completely different data model to your primary platform. In such cases using data transformation can help. Perhaps it’s best to give an example: At an auto dealership System B stores data about the cars in stock. System A is a CRM that manages customer information. We’d like to store some information about the car that a customer has purchased, such as it’s color. System A stores colors as a Pantone color code (go ahead and laugh, I’ve seen worse). Instead of transferring “PQ-2113Cto System A, we can use a Transformation to convert to “PQ-2113CtoBlue, something much more readable to our Sales team.

The goal as a Systems Integrator is to end up with relevant data, and only relevant data.

Synchronization

All of the integration facets are in place, your fields are mapped and filters and transformations are set up to give you the exact data you need to transfer, but timing of your sync can play a pivotal role in the effectiveness of your integration. In an ideal world, all data would be in sync instantly. While this is certainly possible, it’s also costly in terms of computing resources, and therefore setups that require real-time synchronizations are inherently more expensive. Before turning on the switch, think about when your syncs need to run, and how frequently. Make sure the tool you’re using supports sync-on-demand, scheduling and scheduling at a frequency that meets your business requirements.

Security

As a Data Admin, you’re going to be very protective about your data, and rightly so. Data compliance, access and storage are up there on the list of most important factors when considering an integration tool. There are two main types of integration implementations: Middleware and Native. A Middleware solution sits between the two connected systems, and data is passed through it at the time of synchronization. From a security perspective, the data exists in three places, System A, the server running the Middleware tool, and System B. When handling sensitive data, be sure to verify the process used by the Middleware tool and confirm that it at least matches your security requirements. Native solutions skip around this problem by existing within one of your connected systems; your data only leaves to go directly to your other connected system. Security at this level is not always an issue when integrating platforms, but it can certainly be a deal-breaker as well.

Event Logging

A good integration tool will really prove it’s worth through detailed logging. It may not sound like much, but when you’re syncing thousands of records and something goes awry, knowing that your record should contain a semi-colon (;) but actually contains a greek question mark (;) (yes, this is a real thing) can save you quite literally hundreds of hours of troubleshooting, and possibly a whole head of hair. Good logging will provide the information you need at the relevant time, in a format complex enough to portray the problem while being as simple as possible to read. Always make sure to configure logs before running a sync, it’s key yet often underused functionality.

There are a number of options when it comes to integration, and none of them are one-size-fits-all. Be sure to discuss options with your stakeholders and define your business requirements before picking a tool with the right features for your integration. Happy integrating!

Matt Chinnock is a Lightning Applications Developer at CodeScience — helping SaaS companies thrive on the Salesforce AppExchange. Learn more about CodeScience at codescience.com

--

--