What is an Embedded iPaaS?
An embedded iPaaS is an integration platform that is embedded inside another software product so the end user can access integrations to other systems without signing in to an additional service. Like embedded analytics, payments, chat, and voice software products, embedded iPaaS's enable SaaS companies to offer important functionality to their customers without building and maintaining the feature in-house.
With companies using hundreds of software, the need for out-of-the-box integration is rapidly rising. Companies do not want to bear the entire cost of integrating their systems, and now even small to mid-market SaaS companies must offer a dozen integrations out-of-the-box as a baseline to stay competitive. Yet building and maintaining integrations to other products is time-consuming and expensive. As a result, SaaS companies are searching for tools that can make this easier.
Embedded iPaaS's help SaaS companies provide this functionality without diverting their engineering focus from their core product. Most B2B SaaS companies should use a tool that performs some of the functionality of an embedded iPaaS. The exceptions are when integrations are core to the SaaS product, the SaaS product is designed to only be used inside other SaaS products, or it is in a product category that needs only a few integrations.
If integration is core to the SaaS product - for example, a workflow automation tool - then it likely makes sense to own integrations in-house. Alternatively, if the product category needs few integrations - for example, a gmail extension - there is no need to use an embedded iPaaS.
Embedded iPaaS's Relationship to iPaaS's
Embedded iPaaS's serve a very different purpose than iPaaS's. Some embedded iPaaS's have been spun off from existing iPaaS's, while other have been built natively for the purpose of being embedded in other SaaS products.
Traditional iPaaS's were designed for companies who need a tool to help them integrate the systems they are using. iPaaS's specialize in serving different size companies - Boomi and Mulesoft generally serve large enterprises, Tray and Workato generally serve the midmarket, and Zapier generally serves smaller companies, for example - and thus vary in their complexity and structure.
iPaaS's were designed for one company to use to integrate and automate their data flow amongst the many different systems they are using. So, for example, Lion Foods might use 238 software in their course of business. iPaaS's at that level would usually be set up and deployed by engineers and operations, but with the aim of enabling, say, marketing departments to change how data flows between Lion Foods' Salesforce and Marketo accounts by using the iPaaS.
Almost all iPaaS's have visual workflow builders where, in theory, a business user can change the flow of data. In reality, these workflow builders often require deep technical and data knowledge to use, as well as custom coding to meet business objectives. Tools like Zapier, which are aimed at smaller companies, are often easier for a business user to handle, but as a result, they represent less complex data flows and are often more limited in their configuration options.
The key difference between an embedded iPaaS and an iPaaS is that one instance of an embedded iPaaS must provide integrations for dozens, hundreds or even thousands of businesses, instead of for only one business (like Lion Foods). This introduces challenges of complex account management and integration customization at scale.
An embedded iPaaS must enable the SaaS company's product to associate all of its individual customers with their particular integrations, integration configurations, and integration logs (history of data flows and syncs). To be most effective, an embedded iPaaS must also enable the SaaS company's customer to discover, install, configure and troubleshoot the integration on their own.
Evaluation Criteria for an Embedded iPaaS
Given some embedded iPaaS's were spun off from a tool designed for a different purpose - and many newer embedded iPaaS's copied the product model - it is key to examine whether an embedded iPaaS meets enough of the embedded use case to justify the investment and technological entanglement.
Here are criteria to include in an assessment of an embedded iPaaS:
- Does it come with a customizable, front-end user interface where my customers can discover, install, and configure integrations on their own? If you have to build the front-end on your own, how long will it take and how hard will it be to keep the front-end aligned with the embedded iPaaS over time? How hard will it to be surface relevant analytics from the embedded iPaaS in the customer-facing user interface?
- How does it embed in your app?
- How customizable are the configurations my customers can choose from when installing integrations? Whether you have dozens, hundreds, or thousands of customers, there will be a wide variety of configuration needs between your app and other systems. Many iPaaS's limit the configurations based on the fields they visualized and mapped between systems. Consider how well these connectors will meet your customers' needs now and if you continue to grow your customer base.
- Does your customer have to use the iPaaS's visual builder tool? If so, how easy will it be for customers to use it?
- How much custom coding will be needed to meet your customers' integration needs? How challenging will it be to custom code around or in the embedded iPaaS? Is this language agnostic or must developers use a particular coding language? If the embedded iPaaS has an extensive training center and engineers who specialize in the platform, it is likely not easy to learn and will take time and investment. Consider whether your engineers want to specialize in this platform and how hard it will be for you to find new talent if your expert leaves.
- Can the embedded iPaaS handle running all the syncs your customers need at scale when they need them?
- Can the embedded iPaaS handle webhooks?
- If one of the systems you need your app to integrate with changes their API or product functionality, how long does it take for the iPaaS to update their fields and configuration options accordingly? Keep in mind that if a partner product changes functionality, existing integration configurations can become irrelevant to business objectives, even if they don't break.
- If you change your app or API, how long does it take for the iPaaS to update your connector?
- Can you easily see all the installs, uninstalls, and logs from all the integrations and sort them by integration or customer? Can non-technical customer support see integration activity and troubleshoot any customer issues with their integrations?
- Can customers see their integration syncs and logs?
- If a customer's integration is failing, can the customer understand which system is causing the failure or do they always have to reach out to you, regardless of the source of the error?
- Can you easily see how customers are interacting with the integration tiles and their attempted installs?
- How does the customer experience of integrations compare to natively built integrations?
- Can technology partners who own the system being integrated to gain any visibility into how customers are viewing or using the integration?
- If you decide to migrate off the embedded iPaaS, will you retain ownership of any of the code for the integrations or will you have to start everything from scratch?
- Is pricing clear and predictable? Do you have to pay additional charges for each integration, regardless of customer adoption? Is the pricing based on proprietarily-defined terms that are difficult to predict and may not correlate to customer value (like recipe or task)?
Answering all these questions can help assess whether using an embedded iPaaS is a better option than building integrations natively. In addition to building integrations, most mid-market SaaS companies must also build the infrastructure to enable technology partners to build integrations to their app. Most embedded iPaaS's do not help with the latter functionality, but some newer tools do.
Newer Alternative to Embedded iPaaS's: Integration Marketplace as a Service
With the proliferation of SaaS products and businesses demand for integrations growing exponentially, new integration products have cropped up that handle most of the functionality of an embedded iPaaS while also providing additional infrastructure for accelerating technology partnerships.
All large, successful ecosystems, like Salesforce and Shopify, build and own some of their own integrations. These are usually integrations that are of strategic value and top importance to their customers. But the vast majority of integrations in the marketplaces of these large SaaS companies are built by technology partners.
Integration marketplaces as a service (iMaaS) differ from embedded iPaaS's in their focus on enabling SaaS companies to achieve this best-in-class integration ecosystem around their product. iMaaS's undergird an interoperable ecosystem around a SaaS product as opposed to being an integration middleware layer for SaaS products.
An iMaaS is designed to enable native integration experiences at scale and partnerships between technology companies, while an embedded iPaaS is designed to provide more restrictive integration experiences as a product feature.
An iMaaS provides lightweight connectors between systems, but instead of offering a rigid visual builder with pre-defined business logic, it enables SaaS companies and their partners to work directly with each other's APIs to set the business logic of the integrations. This enables a native integration experience that meets customers' needs at any scale.
With a focus on powering interoperable ecosystems and partnerships rather than providing integration as a product feature, an iMaaS provides shared visibility for customers, partners, and the SaaS company over integration usage, installs, and marketplace analytics that leads to further value creation. A SaaS company and its partners can share leads and understand demand, customers have a better integration experience, and customers more easily discover the partner apps they need.
To see an example of an iMaaS in action, request a demo of Pandium here.