Client
An emerging HRIS SaaS technology company that offers a comprehensive solution for small to medium businesses across many industries.
Challenge
Our client has developed a next-generation platform for HR, payroll, and benefits management. As they grow, one of their objectives is to be at the center of the HR app ecosystem for each of their customers, who seek to enhance their core solution with best-of-breed applications. While their product team had built a few integrations directly with the platform, they recognized that this was not a scalable, supportable approach. As such, they saw an opportunity to streamline the process of building and operating integrations with the vast array of HR solutions on the market by using an embedded integration platform.
To that end, they selected Workato to be the integration platform. Workato’s no-code approach and security and governance features enable rapid development and deployment of production-ready integrations and advanced workflows. Since HR systems contain Personally Identifiable Information (PII), a platform like Workato would give their customers the confidence that data remains secure, not just within their application but also as it flows between integrated systems.
While Workato has a vast array of pre-built connectors available for use to facilitate rapid integration development, in some cases, companies may need to build custom connectors to meet their needs.
Our client asked us to build a custom Workato connector with a performance management platform that was popular with their customers.
Solution
Building a custom connector in Workato is generally straightforward, mainly because Workato provides an accelerator based on OpenAPI specifications. This accelerator is a great starting point that significantly reduces the level of effort required, and the automatically generated connector can be further enhanced with custom code.
Building enhanced custom connectors in Workato requires a modest level of Ruby expertise. Our Ruby developer is built upon the OpenAPI-based starting point to ensure the connector had a great UI/UX design for ease of use. We also added dynamic functionality to the connector specific to each environment, and we ensured the code followed good best practices for maintainability.
Outcome
The connector was built in just a few weeks, which in turn enabled the rapid development of integration recipes that could be deployed in a scalable way across their customer base.
Why Build Custom Connectors
While it is standard to build a Workato connector for your own application, a question we often get asked is whether it is necessary to build a custom connector for target applications. In general, we suggest considering the following:
- Does a connector for the target application already exist? If so, does it include the functionality needed to support the use cases you wish to automate? A community connector may only contain a subset of API functionality, so remember, just because a connector exists doesn’t automatically mean it will work for your application.
- If a connector doesn’t exist for the target application, is there a well-documented open API available for this application, and does that API have the functionality for the use cases you contemplate? Remember, the connector can only have the functionality and performance of the underlying API, and given this isn’t your application, you will not be able to control the API itself.
- Do you expect this application to be popular across your customer population, or is it a one-off request? If popular, a connector will reduce the level of effort and risk for each integration. If one-off, it may be better to simply build a recipe connected directly to the API based on Workato’s HTTPS method.
In this case, there was no Workato connector, and the API was publicly available, well-documented, and stable. Since the target application was popular, a custom connector made sense.
