This guide will step you through the basics of integrations at intelliHR to provide a quick and clear understanding of what to expect when deploying an integration.
The Basics
What is an integration?
An integration is defined as any automated flow of information from or to intelliHR. This is often person and job information to keep records up to date to reduce manual data entry. Sometimes this is for more specific business process automation like generating contracts for new hires or logging completed training from a learning management system.
At a high level, integrations act as “automated” administrators. They can perform tasks that a human would otherwise perform, often in real-time and without the potential for human error.
This can be as simple as keeping employees synchronised between intelliHR and a payroll platform, or complex, multi-system integrations with a defined flow of data.
What is an API?
API stands for Application Programming Interface, which is a series of rules and procedures that define how data can be sent and received to an application. This is the "glue" that allows intelliHR to work with other systems.
APIs allow data to be sent to and consumed by intelliHR for many purposes. Integrations use APIs to automate the sending and consumption of data.
Integrations and API are only as good as the quality of data being sent, so it's often important to review the set up of the systems involved to ensure alignment of naming conventions or identifiers.
Post-Deployment
Why do integrations error?
Integrations, like any computer system processing lots of data, will error from time to time. While integrations are designed to minimise errors, they are normal, especially at high volumes of data.
What can cause an integration error?
- Bad Data: when an integration sends or receives bad or missing data
- Failed Connection: something between the two services fails to connect or validate and so the integration fails
How does intelliHR log integration related errors / exceptions?
You’ll receive an email notification from the system explaining the nature of the error, and any required steps to resolve the error. Sometimes the system cannot identify the exact nature of the error, so you may need to reach out to our support team to request further investigation.
How to resolve errors
Some errors are transient and require no intervention. For instance, if the integration tries to connect but fails, the integration may automatically retry and succeed without any human intervention.
Other errors like bad or missing data may require the information to be manually processed in the integrated system, or the triggering event for the integration to be reperformed.
The error message you receive will often include a suggested resolution if one is required.
FAQ
What makes an integration stable?
The best integrations are simple, and send data that exactly matches between systems. The best way to think about is that integrations are a little like equations. The fewer numbers and variables in an equation, the more likely you are to find the correct answer. Equally, the fewer fields and variables in an integration, the more likely it is to succeed.
This is why some integrations can be quite basic while others may be complex and feature rich. If both systems have reliable and stable API layers, they can usually be fully integrated seamlessly, while other systems may have scaled back integrations for added stability and scalability.
Why are some integrations limited?
Integrations often have a series of supported features, and will often not include a feature that a client might describe as desirable or seems to be a ‘no brainer’ as it were. A lot of the time in computer science the difference between something really easy and the virtually impossible is difficult to explain to a non-technical person. Limitations can be from any number of sources: availability of features, stability, sometimes a feature is just a bad idea to implement. We often describe supported features and avoid discussing limitations - it is not a ‘limitation’ of the other vendor, it’s not a supported feature. This can be complicated, so a simple analogy:
Think of purchasing an integration like buying a car from the dealership.
We expect a car to do a few ‘given’ basics - it should have gears, an accelerator, breaks and so on. But, like integrations, cars have a wide range of features and embellishments. Seat warmers, bluetooth, fancy paint.
In the same way, if get the car home from the dealership and discover it doesn’t have bluetooth you wouldn’t say the car is unusable. Equally, you wouldn’t describe an integration as faulty or poorly suited because it doesn’t include a specific feature. Context is always important, as you can imagine one feature might be critical for one client but irrelevant to another in the same way air conditioning may be considered critical for a car in the summer heat of Brisbane but is rarely a consideration for a driver in Norway.
We are always open to adding new features to integrations but a lot of the time it’s not technically possible, may introduce instability, or may already be on our future roadmap!