At some stage, many companies consider building an ecosystem of applications that integrate with their core platform. This both helps to deliver extra value to customers and extra revenue for the company, together with its partners. Such SaaS integrations work via requesting data from an API and receiving webhook events in order to perform their tasks.
In this post, we’ll discuss different considerations and challenges related to implementing a platform to support such integrations: the different types of integrations, technical decisions, balance between giving more flexibility to developers and the interests of the end users, seamless user journey and the different ways to implement an integration ecosystem.
Table of Contents
Types of SaaS Integrations
When it comes to SaaS integrations, we can separate at least two different aspects.
The first can be called data layer integration, or backend apps. Think:
- Adding new methods to collect data on DataDog agents
- Setting up real-time alerts in Slack
- Integrating JIRA issues with GitHub
For data layer integrations, you’re passing data via API and connecting to user data with permission. Some apps only need to read data, while others will also write data back to the user’s account.
We can name the second, UX integrations, or frontend apps. Examples would be:
- Creating designs for Mailchimp emails
- Making 3rd party app-specific actions available in Slack
- Creating charts and widgets from pasted URLs in Confluence
Rather than simply accessing a user’s data, these integrations augment the user experience itself. They might add buttons to the interface or an option to a drop-down menu. There are a different set of considerations, such as limited UI space, that developers need to consider with these frontend apps.
Sometimes a single app feature requires both of them. For instance, it’s hard to imagine a workflow tool without forms and some status reporting to support it. Regardless of whether you decide to use an outside solution or implement yourself, you need to plan for how you’ll handle these aspects, possibly including nuances like managing paid app billing and all the related complexity.
Technical Choices Impact User Experience
This may sound counterintuitive, but purely technical decisions early in the development of an application platform might have a big impact on how users will use it later on. For example, two common approaches to authorization are using the API Keys or OAuth2.
If you initially build everything with API Keys in mind, the users will be forced to somehow store these keys and copy them. This creates a whole host of problems further down the road:
- Secrets might leak. Keys can sneak into logs, emails or be transmitted over an unencrypted channel. This is usually not a problem for short lived OAuth2 tokens
- When using API Keys, you may need to arrange their rotation, but when using relevant OAuth2 flows, this is not a problem
- One key means one set of permissions, which leads to a rigid permissions model and the need to constantly create new keys. OAuth2 instead, uses scopes to grant access to whatever is needed, and the user needs to grant the permissions just once. Here, you can see how it’s done when Auth0 is used with OpenChannel
Even the very best developers can’t achieve perfection each and every time. Standards, conventions and frameworks can help restrict the choices known to create problems in the long run, and nudges them in the right direction. For example, OpenChannel supports OAuth2—and enables developers to easily incorporate it into their marketplaces—because it’s a standard that improves how end users experience your SaaS integrations.
But that’s only one type of integration user experience. There is also the issue of figuring out how much of the UI, developers should control.
If you allow third-party developers to extend your application, it becomes a platform. Any platform has two distinct types of users: developers and the end users. It is necessary to find the delicate balance between the interests of these two types of users for the platform to be successful.
This fundamental conflict requires an understanding up front as to what extent developers are allowed to customize the UI, and which parts of the UI are available for customization.
Clearly, the developers would like to have as much power as possible, including customizing the entire UI to make your application effectively their own.
On the other hand, it’s your responsibility to ensure the primary application and platform work as users expect. Therefore, platforms typically prioritize the end user interests and look at the platform through their eyes. Since the users likely initially came for the main application, it is important that the application doesn’t get worse and ideally, brings new value with the integration capabilities at the same time. Therefore, it is important that UI changes don’t get in the way of the main functions of the application.
Slack integrations that use slash commands are a great example of unobtrusive integrations. Zoom does not take up space in the Slack interface at all, but as soon as the user writes /zoom, the desired widget appears in the chat.
Uploading a Google Doc to Slack shows another way to integrate the UI. Slack has a catch-all lightning bolt button to the left of the message field. Pressing it results in the menu below.
Uploading the document, results in a widget consistent with the previous example.
The user experience with Slack bolt apps—and similar platforms like Atlassian Forge and Shopify Polaris—is more natural than most backend SaaS integrations, because it can happen within the product itself. However, the effort to build, promote and run this type of platform, is far beyond what’s required at the data layer. With integrations at the data layer, only technical issues like authentication, affect the user interface. With these in-application integrations, it’s more important to think how to encourage a seamless experience.
Regardless of the type, you’ll want to make sure that users are aware of the opportunities that the integrations give them.
It is clear that you need to somehow make the extensions discoverable by users who need their features. So how do you solve this problem? There is no ‘one size fits all’ solution, so let’s see what the leaders are doing.
Let’s start with the ‘not as new and trendy, but mature and still loved’, Slack. Everything is optimized to meet the needs of the user. The Main page allows the user to quickly navigate and get a first impression of the platform and apps’ capabilities.
The Header contains a distinguishable Get Essential Apps button that allows you to quickly find what most people need. In fact, this is the first part of the interface that the user’s eye falls on. If you click on this button, you will be taken to a page with categories and search – an interface optimized for use cases of a more engaged user actively looking for something.
The second element present in the header is a GIF, which shows what you can do using various extensions. In this case, these were Salesforce, JIRA, Google Drive and Zoom; an excellent way to quickly demonstrate how different integrations can help. Curiously, as the image is constantly changing, it reliably attracts attention, despite its location in the area rarely used for content.
The reader’s focus then shifts to the main area, with large featured app icons and smaller icons organized into categories. Each of the categories display only the first few icons by default and contains a ‘See all’ link. Where does this link lead? Of course, to the page with categories and search. This allows the reader to see many different categories as possible on the screen.
Then goes the search interface. The user can type keywords here. What page do you think he will be on if he presses Enter? The categories are selected based on the potential interests of the user, for example, there is a category Working from home.
On the left, there is a menu with product categories consistent through all the UIs. It helps the user to discover all the categories in the marketplace.
Let’s now move on to the page with categories and search. It combines the two approaches to searching for information. Those who like hierarchies and catalogs can use the menu on the left. For the rest, there is a visible search bar as an alternative. The interface is clean and convenient to quickly find what you need.
Atlassian is another widely recognized heavyweight. An interesting difference is that The Atlassian Marketplace brings together apps for all the products that Atlassian offers. No surprise, Atlassian Marketplace is a masterpiece of making as much as possible, accessible from a single place.
The most prominent place in the header is given to the search bar. In the main area, we see the new apps and apps by category. The categories in the main area follow the ‘featured principle’. The menu on the left has some innovations. In addition to the sorting order controls, an important place is occupied with ‘by product’ filters. Then, there are filters by app hosting type. Unlike Slack, in order to see more traditional categories like ‘Project management’ and ‘Admin tools’, the Categories section has to be expanded. The section ‘More filters’, working the same way, hides ‘Free’, ‘Vendor supported’ and ‘Beta version’.
Another hallmark of Atlassian is its focus on promoting third party apps on their platform, which indicates the company’s stake on shared success.
Note that the introduction to the world of apps is placed immediately after the very basic Getting Started with Confluence section of the product documentation page.
Another example of minimal yet beautifully effective UI is Mailchimp. The messaging in the UI featuring both search and categories revolves around the user’s intent. Search is easily accessible from the header via Find an integration button. The page lets the user scroll through categories.
The bottom of the page is where the search lives. It’s possible to search for keywords and filter based on activity-based categories, which provides the user with the power to find what he is after.
As we see, the implementations may be different, but some approaches remain the same:
- Making sure the user knows about the marketplace features and different integrations
- Recommendations to help users avoid missing opportunities and to help attract users to the applications
- Search and categories to ensure users find what they want
Create Your SaaS Integration Marketplace
When creating your own marketplace, trying to implement everything using your own resources is always an option, but this option comes with massive capital expenditure, intimidating performance risks and the outright frightening possibility of not doing everything right on the first pass.
Stepping in the same river twice is also not guaranteed; the unique financial, timing and labor market conditions that made the success possible for the others, might simply be no longer there. Because of this, building on the shoulders of a successful solution like OpenChannel might be a better idea.
OpenChannel is a mature, fully featured Marketplace platform and probably the easiest way to launch your App Marketplace. Both users and app developers can register directly on your app marketplace or via single sign on. Users discover and purchase apps from your marketplace using search, categories, tags and app types. Developers are not left behind either: a full set of app analytics and app management capabilities are available for them.
Proven OpenChannel approaches enable the integrations to seamlessly enhance your SaaS platform’s functions and UI. No surprise that companies like Cisco Meraki, DigitalOcean, Smartsheet, Finastra and NBC SportsEngine have made the choice. Check out OpenChannel for free right now and see why.