Your customers find value in your B2B SaaS product. And you are adding more customers all the time. But these same customers want you to provide even more value by integrating your app with the human resources information system (HRIS) they use.
So, your dev team selects an HRIS that some of your customers use and investigates what it would take to build the integration. It seems straightforward. The HRIS has a well-documented REST API. Based on your early discussions with customers, they need a simple one-way data sync between your app and their HRIS. Your dev team agrees that this integration is manageable.
Then, as you gather more data, you find out that your customers currently use more than two dozen HRIS apps. And that number is only going to increase as your customer list grows. Further digging shows that some of your customers expect complex, two-way integrations with their HRIS.
Telling your customers that you won't build these integrations is a non-starter. If you don't build them, they'll find a vendor with a product like yours who will. Larger customers might be okay with building these integrations themselves, but smaller customers will lack the dev or IT personnel necessary to do the job. Turning your integrations over to a third party means you no longer own the customer relationship. But, somehow, you need to figure out how to provide these integrations to your customers.
The challenge is clear. And there is a way forward. Let's check out HRIS integrations in more detail and see how you might best serve your customers.
What is HRIS integration?
Before we get into the details of HRIS integrations, we should note that these are also called human capital management (HCM) integrations or human resources management system (HRMS) integrations.
At its simplest, an HRIS integration connects an HRIS app and another app for data transfer purposes. This usually makes it an HRIS API integration (since modern HRIS apps such as BambooHR, Gusto, Rippling and SageHR have corresponding APIs).
Since HRIS products are used to manage extensive data, HRIS integrations often come into play with employee onboarding. That is, an employee may be set up in HRIS, which is the canonical source of such information, but then subsets of employee data are pushed via HRIS integrations to any number of other apps. After that, employee data changes trigger updates to appropriate apps via the HRIS integrations.
HRIS integrations can be either internal to a company or external (intended for a SaaS company's customers).
Internal integrations are built for a single company's use and function entirely within that company's ecosystem. An internal HRIS integrations may be built from scratch, that is, its code may be custom written by company employees or consultants, or it may be built using an enterprise iPaaS (integration platform as a service). In either case, the integration is crafted to address business needs only for that company.
Customer-facing integrations are built by employees or consultants of a B2B SaaS company to enable data transfer between the SaaS company's product and the other apps its customers use. Such integrations may be built from scratch, built with an enterprise iPaaS, built with an embedded iPaaS, or built with a unified API. A customer integration must usually meet broader requirements than an internal integration because it addresses the varied business needs of several customers.
As you can see from this G2 Grid, there's a large number of HRIS apps in the market today. Because of this, B2B SaaS companies often find themselves needing to build numerous HRIS integrations for their customers.
How do you integrate HRIS with other apps?
Depending on your business needs, an HRIS integration can be created in several ways. Let's look at the most common approaches.
Code an HRIS integration from scratch
Historically, many businesses have chosen to create HRIS integrations from scratch. To do this, they use a dev team that writes custom code for the exact integration scenario. This approach is used for both internal and external HRIS API integrations. This approach is not as common as it once was because tools (enterprise iPaaS, embedded iPaaS, and unified API) are now available to expedite and simplify integration development.
Build an HRIS integration with an enterprise iPaaS
Many companies use an enterprise iPaaS (iPaaS) to build internal HRIS integrations. Enterprise iPaaS platforms include standard API connectors to HRIS and related systems, allowing developers to create internal HRIS integrations more quickly than the old way of coding from scratch. Some companies have even used an enterprise iPaaS to build customer integrations. However, this adds more challenges to the process because iPaaS platforms don't include the functionality (such as an integration marketplace, customer management, and customer dashboards) necessary to support a legitimate customer UX. Enterprise iPaaS are not a good fit for creating customer-facing integrations for HRIS.
Build an HRIS integration with a unified API
A unified API combines multiple APIs within a software category (such as HRIS). As such, it can be a good option for a company that must build the same integration with 20 different HRIS apps (all covered by the unified API). But, unified APIs program to the least common denominator: if 5 of the 20 HRIS apps have some feature, and the other 15 do not, chances are good the unified API doesn't support that feature. Unified APIs are used for external integrations, but many of these platforms do not include access to customer-specific functionality such as embedded marketplaces and customer dashboards. Unified APIs are not a good fit for building integrations to non-standard or custom HRIS apps.
Build an HRIS integration with an embedded iPaaS
More and more B2B SaaS companies use embedded iPaaS to create customer integrations. These platforms include standard API connectors to HRIS and related systems, streamlining the integration build process. However, unlike enterprise iPaaS, embedded iPaaS is optimized for productizing customer integrations, ensuring that the integrations and associated processes will properly scale with customer growth. And, unlike unified APIs, embedded iPaaS supports the configurability and complexity required to build integrations with every app in a horizontal – not just the standard ones. Embedded iPaaS includes everything necessary to build, deploy, and support real-world customer integrations for every market sector. Embedded iPaaS is not a good fit for creating internal-only integrations for HRIS.
Benefits of HRIS integration with an embedded iPaaS
Of the options listed above, an embedded iPaaS provides the greatest benefits when building HRIS integrations for your SaaS customers. Let's check out those benefits.
Save engineering time
Building HRIS integrations for B2B SaaS customers without using the purpose-built functionality of an embedded iPaaS takes much more dev time investment than most companies can sustain.
An embedded iPaaS includes a low-code integration designer, a library of built-in components, an integration marketplace, an embedded workflow designer, integration deployment and support tools, and a cloud-native infrastructure – absolutely everything needed to build, deploy, and support customer integrations successfully. No wonder companies report dev time savings of up to 80% after implementing an embedded iPaaS.
Increase win rate and sales velocity
An embedded iPaaS allows your team to create reusable, configurable HRIS integrations in days or weeks instead of months. Doing so lets you say "Yes" more often when an HRIS integration is part of the functionality your prospects need before they become your customers. Based on a quick dev turnaround, you can frequently include desired integrations with initial customer onboarding.
Customers often want your product to do X, even if X wouldn't necessarily be helpful for your overall product direction. Integrating with an HRIS may allow you to offset these functional gaps by giving customers another way to solve that business need.
Provide a great UX for integrations
When you create HRIS integrations for your customers with an embedded iPaaS, you ensure that those customers will have a first-class integration experience. Such integrations are obvious (and essential) product functionality.
Further, your customers won't suffer from the classic black-box integration experience, where they rely entirely on your support and dev teams to tell them what is happening with their integration. Instead, customers can enable, configure, and even support their integrations based on having detailed access to integration configuration, status, log, and alerting data.
Change is a constant, and an embedded iPaaS makes it easy to make needed changes to integrations while simultaneously managing and versioning the underlying code within your standard CI/CD processes.
Improve your customer service
When you use an embedded iPaaS for HRIS integration, your integrations run on a purpose-built infrastructure that has redundancy, scalability, and security built-in. This greatly reduces performance issues and other problems that occur with integrations.
Since no time is spent on infrastructure issues, your support team can focus on the integrations proper. This is where the deployment and support tools built into the embedded iPaaS come into play. You can empower your non-devs to do much of the support that historically has been handled by devs.
You can also set up your customers to self-service their HRIS integrations, allowing them to resolve many minor issues before you even know about them. Customers can view, configure, monitor, and otherwise directly interact with their integrations without relying on your support teams for first-level support.
Reduce customer churn
Using an embedded integration platform for your customers' HRIS integrations can help reduce customer churn by making your product essential to your customers because it's connected to their other critical apps. The platform can elevate embedded integrations in visibility and value, establishing them as key product differentiators.
For customers, leaving your product with its HRIS integrations means removing your app and losing an essential piece of their workflow automation. Finding another vendor to replace your app and its HRIS integrations drives up the cost of switching, thereby decreasing the probability of churn.
HRIS integrations use case
Now, let's look at an HRIS integration example. We are using the ACME app as a stand-in for your SaaS product in this example and showing the integration steps within a low-code integration designer (part of an embedded iPaaS). You'll notice that this example is relatively simple. HRIS integrations can run the complexity gamut, from very simple to ones with hundreds of steps and many different flows.
BambooHR
Our example is an integration between BambooHR and your ACME app. This integration performs an initial employee record data sync from BambooHR to ACME.
We'll look at the integration as shown in the designer and explain what is happening.
- We start with a BambooHR webhook to make the connection between our integration and BambooHR.
- Next, we get BambooHR to give us a list of all the employees for our organization.
- Then, we start a loop function, allowing us to parse the entire list of employees.
- Within the loop function, we will first map the fields from a given employee record in BambooHR to the schema we need for employee records in ACME.
- Then, we'll append each mapped employee record to each previously mapped employee record.
- Now that the loop is complete, we must assemble all our employee data into the format to post to ACME.
- And finally, we send the data via HTTP POST to the ACME app.
Keep the data flowing
No matter which HRIS integrations you need to build for your SaaS product's customers, an embedded iPaaS allows you to build, deploy, and support those integrations as first-class parts of your product.
Schedule a demo. We'll show you how Prismatic supports powerful, reusable, configurable integrations between your SaaS product and your customers' HRIS apps.
