Because of the power and flexibility of the Salesforce platform, there are multiple ways to exchange data between Salesforce and internal or external systems. These range from simple built-in Salesforce tools, to developer-built API-driven data interchange, to a wide variety of commercial data interchange tools. No one solution is right for everyone - in fact, many organizations use multiple solutions to accomplish their data migration needs.
Here at Integrate.io, we want you to understand the options available so you can make an informed technology choice to meet your business needs. Let’s look at the three main data migration strategies to see which fits your application.
Salesforce’s flexible and fast reporting can be used to export Excel and text files for transfer to other systems. The Data Loader can be used to load data from outside systems into Salesforce in most editions of the tool. Putting these reporting and load capabilities together, an administrator or skilled end user can create an integration pipeline without writing a single line of code.
The main strength of this approach is simplicity and accessibility - if you’ve worked on Salesforce for any length of time, you’ve written reports and used the Data Loader. The main limitation of this approach is the manual effort and careful oversight involved, especially during the data load. Often, other systems producing data for loading will have bad data or formatting issues, and it’s not possible to load the data without some grooming. Even so, this simple approach is a great way to start integrating Salesforce with the rest of the enterprise, and to prototype integrations that will later be coded or implemented in a third-party tool.
For more information on Integrate.io's native Salesforce connector, visit our Integration page.
Using the customer tracking example, this integration would have three components:
- A report of object ids and other customer information that would be run periodically to export new customers. The person running this report would run and export a report of accounts created after the last report.
- An upload to the external customer tracking system that would run a process which would export a list of customer ids in CSV format.
- A data loader step that would use the CSV file to update the custom field containing the external account ids.
2. Salesforce API
Salesforce has a rich and powerful Application Programming Interface (API) that can be used by programmers to upload and download data. Using a variety of supported programming languages, programmers can retrieve data from Salesforce using queries written in the proprietary Salesforce Object Query Language (SOQL). Programmers can also write code to insert or update standard or custom Salesforce objects.
There are very few systems with an API as complete and flexible as the one Salesforce provides, but the main drawback of the API integration approach is the need for programming. Each integration using the API will require development resources and an integration specification, and it will incur the same risks and costs of any other development project. If you are in one of those rare organizations that has a surplus of developers, count yourself lucky and use the API. Those of us in the real world will probably try a different approach.
Using the customer tracking example, a developer would create API code with SOQL queries like this one:
SELECT CreatedDate,Id,Name,Phone,ShippingAddress,ShippingCity,ShippingCountry,ShippingPostalCode,ShippingState,ShippingStreet
FROM Account
WHERE CreatedDate = LAST_N_DAYS:30
Ideally, this code would call APIs in the customer tracking system to directly insert the new customers, and obtain a customer account number. Then, the code would call the Salesforce Update API to insert the new account number, since SOQL is a query-only language.
3. Third-Party Integration Tools
Somewhere between writing your own code and a more manual approach is the use of third-party tools. These tools can be as simple as a one-way extraction program, or as complex as a tool that has its own programming language. These tools shield the user from the details of the API, and many of them have a drag-and-drop interface that makes it easy to create an integration workflow. Often, these tools are cloud-based so there’s no need for the hassle of an on-premises install.
A good third-party tool will include data cleansing and verification technology to make sure the data being transferred in the integration is not corrupt. Quality third-party tools will allow scheduling and process automation so manual intervention is for exceptions, not the norm. The better third-party tools have a wide variety of data targets, including most of the popular cloud data warehouse platforms (Amazon Redshift, Snowflake, Google BigQuery, etc.), relational databases (Oracle, SQL Server, MySQL, etc.), and the widely-available REST API. The latter two targets are vitally important in an enterprise context, because integration targets in the enterprise are often systems “inside the firewall.” A good tool is bi-directional: it can read from and write to your Salesforce instance.
In addition to the obvious benefit of avoiding programming, third-party tools promise faster implementation and higher-quality integrations. Implementations can be fast because the tools are pre-built, and integration quality can be high because of built-in data validation and cleansing tools. The drawbacks of third-party integrations are cost, vendor stability, and the possibility that the integration tool may lack a capability necessary to fully implement the integration.
Choosing an Integration Technology
Which of these three basic strategies your organization will use to migrate data to and from Salesforce is going to depend on multiple factors. Some of these factors are related to the integration itself:
- If your needs are simple and infrequent, using built-in Salesforce tools might be your best bet.
- If your needs are complex or frequent, you might want to use a third-party tool or have your development team build your own API interface.
Your organization’s funding and technical resources are another factor to consider:
- If you have developers with time on their hands, they can build you a custom API integration. Based on our experience, you should also count yourself lucky!
- If you don’t have resources to do anything else, you might use the built-in Salesforce tools to run your integration even if it is complex.
- If you don’t have developer time, but do have some resources, a third-party tool might fit the bill. Just be sure the tool you choose can address a reasonable set of future needs as well as your current integration challenge. You don’t want to change tools next year just because your current tool lacks a feature (like bi-directional data exchange) that your current integration doesn’t need.
How Integrate.io Fits In
As a third-party integration tool, Integrate.io has a number of strengths:
- We integrate with almost any modern tool, including cloud data warehouses (RedShift, BigQuery, Snowflake and others), relational and no SQL databases (including MySQL, Heroku PostgreSQL, SQL Server, MongoDB), and any system, cloud or internal, that has a REST API interface.
- Our Salesforce integration is bi-directional -- we can read from and write to standard or custom Salesforce objects.
- Since Integrate.io can securely access data behind your enterprise firewall, it can be used for integrations between Salesforce and your internal systems.
- Integrate.io uses a drag-and-drop interface that lets non-developers build data pipelines between systems without writing code. Or, our skilled data engineers can build pipelines for you, if you don’t have resources to do it yourself.
If it sounds like Integrate.io might be the answer to your integration challenges, we’re happy to provide a demo, a seven-day free trial, and a free setup session with our implementation team. Just contact us here or give us a call at +1-888-884-6405.