Custom HR Office integration development

We regularly integrate HR Office with payroll providers such as NMBRS, Visma-Loon, Loket and ADP; with ATS platforms such as Recruitee, Homerun and BambooHR; with SSO/IAM solutions such as Microsoft Entra and Okta; with accounting packages such as Exact, Twinfield and AFAS; and with onboarding, workforce and time-registration tools. Which system sits on the other side mainly determines how much custom work the middleware layer needs. The approach and the GDPR foundation stay the same.

That depends on the type of event and how sensitive the data is. Hire and terminate events (account creation in SSO, payroll record) are usually built in real time via webhooks so that a new employee can log in straight away. Salary changes to payroll can run in batches at month-end, since the payroll run depends on them anyway. Absence notifications go to workforce planning in real time, with periodic reconciliation to accounting. We make that choice explicitly for each flow, together with your HR and finance teams.

A source-of-truth conflict is by far the biggest pitfall in HR integrations. For each field, we record which system is leading: HR Office is usually the source for personal, contract and role data; payroll is leading for gross salary history and year-to-date totals; SSO is leading for account status and groups. If a change occurs in a non-leading system, the result is either a warning or a forced override to the leading system, depending on what is legally and operationally correct. No implicit "last update wins" logic.

For each integration direction, we document which fields are exchanged and why (purpose limitation). Fields that are not necessary for the target system are not sent, even if the API accepts them. Special category personal data (such as reasons for absence) only travels where legally required and with an explicit legal basis. Every change is recorded in an audit log with timestamp, source system, target system and the fields changed — not the values themselves, to prevent leaks through logging. That material feeds directly into your record of processing activities.

For light, linear integrations between two systems, iPaaS is perfectly adequate and we recommend it. It becomes too limited once: the volume exceeds what Zapier tasks can handle, the logic branches across more than two systems, conflict-resolution rules are needed, purpose limitation per field must be visible, or retry and idempotency guarantees are required that iPaaS does not reliably provide. Custom middleware costs more up front, but avoids the lingering maintenance problem that makes iPaaS flows unmanageable after a year.

Almost every HRIS integration runs into a field that exists in the source or target system but is missing or limited in the API. We then choose between three options: an intermediate layer that manages the data outside the API (for example custom fields or an extension table), a temporary manual step that is explicitly documented in the process, or consultation with the vendor to extend the API. We always document which fields travel outside the standard API, rather than hiding them.

The cost is determined by the number of systems to integrate, the complexity of the field mapping, GDPR requirements (municipalities or healthcare are stricter than an average SME), the required sync frequency, and the amount of custom work in conflict resolution. Ongoing management, monitoring and support also affect the total investment. We always provide a clear quote following a no-obligation analysis of your situation.

Yes. Appfront regularly takes over existing HR integrations, even if they were originally set up by another party or via an iPaaS. We review the data flows, error handling, GDPR documentation and monitoring, record how things currently work, and propose improvements. From then on, we can handle adjustments, extensions and ongoing management — including timely API key rotation and periodic security checks.