RelayIQ: Integrations That Enable an App You Never Have To Leave

What if you could build integrations so seamless that customers could interact with other products without leaving yours?

It’s a win-win. Users love to work in one place. Apps prefer to keep you in their place.

The challenge is: apps represent data in a wide variety of formats with complicated rules and behaviors. Just because you know how to send data back and forth doesn’t mean you know how to enable a human or AI agent to pick the right data to send. This was the unique challenge we set out to solve when building Visor.

We had one advantage over everyone else: our origin story. Most companies build a product first and integrations later. We built the integrations first, and then we built the Visor application on top of it. This enabled us to take a first-principles approach to integrations. It’s not just about exchanging information, it’s also about exchanging the “format” of that information.

At first we wondered: why had nobody else solved this important problem? But as we built our technology, the answer came soon enough: it’s really, really hard. Fortunately, I’m pleased to say we’ve invented the necessary technology (and mindset) for solving this problem, and the thousands of Visor users can attest that it works. But that’s just the beginning of what I believe this tech can help us achieve.

My name is Patrick Shanley, I’m Head of Engineering at Visor. I’m going to start by telling you about why Visor’s integrations are built so differently than anything else out there — and why that matters.

Finding the opportunity gap

At heart, the Visor team consists of problem solvers willing to ask questions. The question that started it all was: why have so many teams eschewed using their SaaS apps in favor of using spreadsheets?

People wanted flexibility and the ability to collaborate with one another. That speaks to a spreadsheet. But they needed the data from their SaaS apps to flow in and out of these spreadsheets to match the way they work. They were using spreadsheets as a way to build the UI they needed for the data inside their SaaS apps.

We eventually solved this with our unique integration system, which we call RelayIQ.

RelayIQ’s architecture enables bi-directional syncing by standardizing third party API functions into a universal language of Create, Read, Update, Query, and Search operations. It is smart enough to read the unique metadata of each customer’s instance (like dropdown options, custom fields, validation rules, and relationships between objects, and even special sorting and filtering behaviors) to create a configuration blueprint that is standardized across all connected apps.

But how did we get to that point? And what else can RelayIQ do?

Why this opportunity fascinated us

When we set out to create what would become Visor, we spoke to project managers to find out more about what problems they faced.

Over and over, we heard about complex, teetering tech stacks. As of 2024, the average tech company had over 100 SaaS applications in their stack. That’s exhausting for anyone to keep up with, but PMs were getting the brunt of balancing a different tool for every team.

We aren’t the only ones to think this is a problem worth solving. There’s now a major shift underway as companies try to unify experiences and keep customers in one platform.

Now that AI is becoming essential to the way we work, it’s more important than ever to integrate data to give AI the information it needs to accomplish anything. For AI agents to function as intended, in a genuinely helpful way, they need to have access to the applications where humans are working. They need to be able to pull data from documents, CRMs, emails, and more. While tools already exist to help exchange data between apps, we’re still struggling to standardize information understanding when it can be housed in so many different ways.

The problem Visor wants to solve is going to be hugely relevant to AI success in the future, especially in terms of data interpretation. But in 2016, when we started, this wasn’t the top issue of the day. We wanted to connect people by bringing their apps together even then. The only question was: how?

Why it’s been such a hard problem to solve

Existing integration technology does a really poor job translating experiences between apps.

Product-to-product integrations are generally one-way. They might pull information from an outside source, but lack the ability to push changed information back to its source. For instance, if you use Asana’s integration with Roadmunk, you can see Asana information within Roadmunk, but cannot push changes to your Asana instance from Roadmunk.

In fairness, creating a successful bi-directional integration is very tricky to do. Even when integrations are two-way, they often skip over important fields because the work of normalizing the data on both sides is just too much.

Different SaaS products vary wildly in how they lay out their information. There’s no one unified format for understanding how to present this information to users in an editable way.  If you know the exact values to send there are uniform systems for exchanging data between machines. But a human (or even an AI agent) is unlikely to know exactly what values are available and how to format them.

The classic example of this problem is dropdown choices in Jira. The IDs used to send the values to the server are not the same as the labels humans choose.

We knew that the desire to solve these problems was already there. But in 2016, the landscape was missing a good way to do so.

Surveying the biggest challenges – and creating our own solutions

So what could we make to solve these problems? We knew we wanted a bi-directional set of integrations. We knew we wanted them to be clearly understandable to the end user. We knew we wanted that information to be easy to share and show off.

To make that happen, we had to clear a few technological hurdles. Successful companies full of smart people have run into these problems and found different solutions.

Order of programming operations

We needed to create a program that could push and pull data in the right order, and understand how to work around missing information.

Example – Atlassian: Creating a Jira issue requires entering certain values first. That needs to happen before you know what choices to show in other areas. For instance, when you’re creating a Jira Issue, you need to first select the Project. Only then will you know what Issue Types (Epic, Story, Task, etc) are available. After that, you’ll know what Statuses you can set.

There’s no universal system for APIs that enables understanding this complicated behavior. And while there is online documentation, it’s rarely complete, accurate, and detailed enough to rely on 100%. That’s why I’m not optimistic about AI’s ability to consume API documentation and figure this problem out. Doing this work requires trial & error as well as a deep understanding of the human experience of working with this data. That made it a problem worth solving.

Creating an issue in Visor’s own Jira instance

Language for humans, not computers

Some other apps have generic formats and esoteric coded errors that aren’t useful for the user. And every app represents these errors and problems in a different way. We wanted to make sure that these messages were always something that could genuinely help our users, and that looked the same no matter where the issue originated.

Example – Salesforce: Salesforce can be especially tricky to integrate with other SaaS apps because it’s so unique. Salesforce reference fields come through the API as IDs, not the labels humans expect. It also treats multi-select dropdown choices as if they’re a text field, adding semicolons between choices. However, other apps treat drop down menus differently, using different syntax.

Fields in Salesforce

Well-respected companies filled with brilliant engineers have struggled to clear these hurdles of finding a unified format for understanding the shape of data within various apps.  Or perhaps they didn’t have the same requirements we had and didn’t develop solutions with this robustness. That’s why we felt it was important to go back to a first principles approach to try and break down the problem into small pieces, finding the root of each issue and beginning from that point, rather than trying to simply iterate on the existing patterns for developing interoperable integrations.

Visor’s Fix

Let’s say you’re trying to sync your data between Jira and Visor. But a team member deleted your status field in Jira. As Visor and Jira sync with one another, our integration system notices the problem and gives you a plain language error message. You can easily understand this message, because it explains a field may have been deleted in Jira, and you may need to fix it to continue to fully sync.

Salesforce errors

Visor cell error

We use machine intelligence to pattern-match errors and turn them into something any human could understand right away instead of leaving it a numbered mystery.

Fixing errors in Visor

But we took it a step further: we prevent users from accidentally causing syncing errors in the first place by making sure the data in each integrated field exactly matches the format of the data in its native app. We preserve the “type” of field between apps – drop down menus in Jira are drop down menus in Visor, number fields in Salesforce are number fields in Visor, etc.

Using CloudStore, our integration system double-checks everything before pushing. Like a server at a restaurant reads your order back to you to confirm it’s correct, our machine intelligence checks the changes against the rules for each integrated app, making sure that it won’t cause problems.

I don’t know of any other applications built on the basis of double-checks, but it’s central to Visor. And this all happens so fast that most users never realize it’s happening at all.

How we broke through

While we knew these were problems we wanted to solve, we didn’t initially know the shape that solution would take.

We started with solving the problem directly in front of us: how do we represent any salesforce field, no matter how advanced, in our own product. At the time of our founding in 2016, we began by building a chrome extension that equipped sales teams with the ability to see & edit salesforce data from anywhere they went on the web. 

But we didn’t just want a system that worked with Salesforce data. We wanted to be able to deploy this technology for any app our customers needed. And that forced us to invent a common format for storing the shape of integration fields. Crucially, our format had to remain faithful to all the nuances of the source data.

At the time, 2016, big data was still the craze, and integrations focused on equipping data scientists with the tools to get their data into centralized “big data” warehouses for analysis.  But these systems were never designed to enable humans to work with the data. To pull off the new system we wanted to create, we had to ignore that “state of the art” integration tech.

It turned out that the most basic answer was deceptively simple. So simple, we call it cake.

All the apps we integrate with today (and will integrate with tomorrow) have very different formats for their data. They use different fields and formats, rules and validation, objects and types.

But in Visor, the frontend UI for each integration looks uniform.

We’ve developed a canonical format in which to represent the data structures within a customer’s SaaS instance, which we call the connected app integration configuration. We abbreviate that CAIC (and pronounce it like “cake”). Each CAIC enables the user to work with information from a range of different integrated apps in the same way

You might be familiar with a concept called the OpenAPI standard, a uniform way that applications have made available information that can be exchanged with their app. It’s helpful to think of those elements as verbs: they’re actions that can be taken. In comparison, Visor’s CAIC is a system for standardizing the nouns: what data is in the application and how it is structured.

Using RelayIQ and CAIC, we’ve considered what data needs to be available in any given integration. We’ve also stopped to consider what that information looks like when displayed visually.

A Visor workbook featuring multiple integrations with Asana and Salesforce

The different uses for RelayIQ

A huge part of Visor’s core DNA is that it’s built for complex, nuanced integrations. Our integrations aren’t just something we slap on top of the app; we’ve been dedicated to making things work the way the user expects the first time.

When you’re an integration-platform-based-software, you’re going to be getting data from many different places and they’re all going to handle it slightly differently.

Using CAIC, we’re able to sort through the information following between Visor and an integration, translate it to a result humans would expect to see, standardize the final format so that everything is user-friendly and obvious.

Our integration system makes the Visor app possible today. But that’s just the first application of technology that can do so much more. Our long-term plan is to use RelayIQ to create a totally new product, one that enables bi-directional data editing for any other app. This would be something other software could incorporate to make it beyond simple for users to edit all their data, in any app, from one place.

Foolproof integration imports

The import experience can be a huge hassle for users. We determined it was a major frustration in our early market research. So we set out to make it extremely simple and user-friendly.

Integrations require minimal effort from the user – just click a button, make some simple choices about what to integrate, and Visor handles the rest.

Options for integration management between Jira and Visor

We’re especially proud of how this shows up in our Asana integration. It’s flexible, allowing you control over the specific fields you want, with the data you need to see in your import. Best of all, that double-checking and unified frontend design means that this information will be correct the first time.

Anywhere you might need live data across clients, and you need it accurate right away is a palace where this system could help you.

Keeping users in the app

Because of all these intelligent, intentional integration elements, our integration system allows users to make changes to other apps without ever leaving Visor.

Making a change in a Visor record updates that record in Jira

From a user standpoint, that’s incredibly useful – it’s great to have it all in one place. From an app’s standpoint, it’s wonderful to keep users within our tool and not “leak” them into others.

Say your product team uses Jira, but your marketing team is using Asana. How amazing would it be if you were working inside Jira and could see and update marketing’s Asana tasks?

What if you were on the customer success team, working from Salesforce, and could create Jira tickets for customer issues without ever leaving Salesforce?

This is an elegantly engineered solution to an extremely challenging prospect. Every project management software out there has a complicated set of rules and fields, and they almost never support one another’s systems. It’s like puzzle pieces that don’t quite fit. At Visor, we’ve found a way to program requests in plain English and see the results reflected the exact same way on Visor’s frontend.

This technology could allow any app to prevent user leak by focusing on functional two-way integrations.

In Visor, your Asana, Salesforce, Hubspot, and Jira data all look identical – even though that’s a lot of work behind the scenes to import it all in that way.

Now that we have this technology, we know that we can scale up to many, many different integrations while managing the complexity, because we only need to deal with a single programming format using CloudStore.

Real time, uniform integrations were just the beginning

Now that we’ve developed the RelayIQ technology, we’re able to solve bigger and more interesting problems facing PMs. But project and portfolio management is just the start.

With the Visor app as a living, breathing proof of concept of what this technology can do, I’m excited about how future partners will be able to revolutionize the future of work by bringing fully interactive two-way data experiences to users, wherever they are.

The Visor app is just one exciting application of a technology that I know will dramatically change how we work.

The question is now just: where else can Visor’s technology be deployed to revolutionize software experiences?

Patrick Shanley

Patrick Shanley

Head of Engineering

Visor's Head of Engineering, pushing toward delivering a best-in-class product to change the way people work and interact when their tools fall short.

New Jersey