Integrations are the unsung heroes of many applications and the silent gatekeepers of data communication between platforms. Yet many decision-makers overlook the quality of an integration when evaluating products. It's often hard to know how well-built an integration is before you're actually in the product using it. Most platforms have integrations that "check the box," but they often vary in quality. Well-built integrations can make even the most simple platform a powerful tool. Poorly built , however, can lead to frustration, slow performance times, technical difficulty, and misinformed decisions. integrations In this post, we explore the benefits of well-built integrations, common integration pitfalls, and what building with an “integration-first” mindset looks like. What’s an integration? An integration is a communication channel between two applications. More specifically, it is the process of combining separate software elements into one system. For example, let’s say you store your contact or lead information in a CRM system, but you use a gifting platform to send items or rewards to these contacts. Integrating them would allow you to see and access all your contacts from inside the gifting platform. , applications, APIs, and devices across an organization allows you to connect different systems’ functions and use these functions (ideally) seamlessly across your tech stack. Connecting data Benefits of a Well-Built Integration When an integration is working well, it can provide a multitude of benefits to your organization, such as: Improved Error Messaging: A good API will allow users to see clear and well-defined error messages (and not just a vague error code) when things go wrong. Integrations are constantly changing; knowing what the failure code means or where a failure took place in the integration is extremely important for problem-solving. The best-built integrations communicate failures effectively and concisely, allowing users to reach a solution faster or even fix or troubleshoot issues themselves. do Seamless Information Transfer: A well-built integration allows two applications to communicate smoothly with one another. “Well-built” means that information comes in the way you would expect it to and requires little to no mapping or configuration to work properly. A well-built integration should do all the heavy lifting so that a user can simply connect two applications and continue working. A Single Source of Truth: This buzzphrase is all too common amongst tech apps these days, but with the right integration, it’s actually true! With so many different products often making up a business’s arsenal, a good integration–or series of integrations–allows users to take information from all their key applications and work with it in fewer (or one!) places. Thoughtfully built integrations allow information across all platforms to be in sync, accurate, and consistent. Stale or inaccurate data can cause serious issues for any company. Pitfalls of a Poorly-Built Integration When an integration doesn't work well, it can cause serious headaches and problems across multiple departments. Some common pain points with integrations include: Some common pain points with integrations include: Data Loss: Sometimes, not all the information you want gets pulled through an integration. Certain fields might be missing, incompatible, or mistranslated during the process of information transfer. Other times, making a mistake in one application can cause erroneous data or issues to be exported to the integrated application if a user is inexperienced or unfamiliar with how the integration is set up. It's crucial to make sure all your integrations are mapped correctly and that the appropriate teammates know how the transfer of information works. Latency and Performance Issues: Adding API calls, which is how most companies build integrations, adds an extra step in your response path, which can slow down app performance. Also, if not configured correctly, they can become a in your system. Many applications do not build their integrations with scalability or adaptability in mind, so when the application they are integrating with changes, the whole system can fail and need to be remapped or rebuilt. single point of failure Another example of a possible issue is an "infinite integration loop." Some third-party integration solutions run on automations that can conflict with one another and cause the information to “bounce back and forth” when a field is updated in one platform, and the same field is updated in another. This can get messy quickly as the systems begin to fight with each other on who is the ultimate source of truth, creating an “infinite loop” as the automations trigger each other over and over again. Unhappy Customers Nothing is more upsetting for a customer than being promised seamless, trustworthy integrations and then finding out things don’t work as expected. Even worse, some customers are sold well-rounded or promising integrations during the demo process, only to purchase software and find out the integration barely works or doesn’t fit their use case without extensive mapping or reprogramming!  Often, it is much worse: you get dead-ended. The fields you want aren't available, or the functionality you need is simply "too advanced" and unsupported. Being baited with the promise of something that will make your workflows more efficient and accurate, only to find out it's janky or hard to set up, can leave a bad taste in anyone's mouth; it also can be a main cause of loss of trust and customer churn. Building with an Integration-First Mindset Some applications, like , were built with integrations in mind from day one. While many applications focus on shiny UI to get users interested, Visor first. Visor went “under the hood” For example, other applications require field mapping when setting up an integration. When other apps ask you to map fields, it's basically the configuration information for your integrated instance. However, it puts weight on the user setting up the integration to ensure everything maps correctly and rules and automation are applied where necessary or rebuilt where possible. Visor wanted to take the weight of integration setup off of users so they could get value faster. Using and storing it in a uniform way across all the apps allowed Visor to handle field mapping on the backend, so the user simply has to select an integrated app, the fields they want to see, and get to work! “We’ve standardized meta information that services provide and turned it into one platform-agnostic format. Our code inside Visor knows how to present fields in a way where users make fewer mistakes,” says Patrick Shanley, Principal Engineer at Visor. metadata about the fields provides value faster by knowing how to follow the rules set by your integrated applications. For example, you can’t assign a person to a project they aren’t on in Jira, you can’t attempt to write to read-only fields, and values that exist as numeric IDs in data, such as contact identifiers, are translated into a user friendly and readable format. Visor Do It Well, Do It Right Almost every prides itself on offering some form of integration. As all companies seek to be a “source of truth” or information centralizer, it's difficult to know when an integration is well-built and when it's just slapped onto a product as an afterthought. But not all integrations are created equal, and once you’ve worked with enough of them, it’s easy to tell which integrations just “check a box” and which integrations are comprehensive solutions built with the user in mind. SaaS app

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Integration Rules: The Backbone of Data Communication

Too Long; Didn't Read

@visor

Credibility

RELATED STORIES