Short answer
An HRIS and AI integration is a controlled exchange of defined data for a defined workflow. Start with the minimum fields, map permissions and lifecycle events, decide how errors reconcile, and test with fictional records. Do not select an architecture until the vendor demonstrates the exact connection it supports.
Start with the workflow, not a connector name
“Integrate with our HRIS” can describe very different jobs: loading an eligible roster, assigning people to groups, authenticating users, returning a completion status, or writing a reviewed record back. Each job has a different data contract and risk.
Write one integration statement:
For the onboarding-conversation pilot, HR operations will provide the active participant roster and approved group attributes. The conversation system will return campaign delivery status to the authorised HR reviewer. No conversation text, theme or individual score will be written to the HRIS.
This fictional statement is narrow enough to test. It identifies the source, destination, purpose and an explicit write-back boundary.
Choose the smallest viable exchange
An automated API is not always the best first step. Compare patterns against the pilot's volume, update speed, error cost and security requirements.
| Pattern | Suitable question | Control to require | Limitation to record |
|---|---|---|---|
| Manual approved file | Can a bounded pilot run with a fixed roster? | Named exporter, protected transfer, validation and deletion date | Updates do not arrive automatically |
| Scheduled file exchange | Does the roster need regular batch updates? | Schedule, encryption, manifest, duplicate handling and reconciliation | A change may be stale until the next run |
| Read-only API | Does the destination need current approved fields? | Narrow scope, service identity, rate limits, logs and error response | Source availability affects the workflow |
| Event feed or webhook | Must joiner, mover or leaver events arrive quickly? | Event validation, replay handling, ordering and monitoring | Duplicate or out-of-order events are normal test cases |
| Controlled write-back | Is a reviewed output needed in a named HRIS field? | Field owner, schema, approval, idempotency, audit and rollback | A bad write can alter a system of record |
Ask the vendor to label each connection as generally available, account-dependent, custom, simulated or unavailable. A slide showing an HRIS logo is not evidence of a functioning connection.
Build a field-level data map
Do not begin with “all employee data”. Record each required field and reject anything without a purpose.
| Field | Example entry |
|---|---|
| Business purpose | Invite eligible new starters to one onboarding conversation |
| Source system and owner | HRIS worker roster, owned by HR operations |
| Source field | Worker ID |
| Destination use | Stable delivery reconciliation, not an employee score |
| Allowed values and format | Documented identifier pattern; no display meaning |
| Transformation | Pseudonymous campaign key created for the exchange |
| Update rule | New value replaces the earlier roster status after validation |
| Access | Integration service and authorised HR operations reviewer |
| Retention and deletion | Period and trigger approved for this workflow |
| Missing or invalid value | Reject to a controlled queue; do not guess |
| Correction owner | Named HR operations contact |
Repeat the row for email or delivery channel, organisational group, locale and dates only if each is necessary. Avoid importing pay, health, absence, performance or demographic fields merely because they exist in the HRIS.
The UK Information Commissioner's Office describes data protection by design as work that begins during design and continues throughout the lifecycle. Its current guidance says default processing should be limited to the personal information necessary for the specific purpose. An organisation must apply the rules relevant to its processing and workforce; a field map is evidence for that review, not a legal conclusion.
Separate identity, access and analysis
One employee identifier can quietly turn a group-listening workflow into individual monitoring. Decide whether the destination needs an identity for delivery, analysis, both or neither. Delivery identity should not automatically become permission to expose conversation content or create a personal HRIS attribute.
Use a permission matrix:
| Role or service | Read from HRIS | Write to destination | Read output | Write back to HRIS |
|---|---|---|---|---|
| Integration service | Only approved roster fields | Validated roster | Transfer status | None unless separately approved |
| HR operations | Source and exception queue | Corrections through owned process | Delivery and reconciliation | Approved operational fields only |
| HR reviewer | Relevant group context | Review decisions | Group output and permitted source context | No automatic write-back |
| Manager | No integration credential | None | Action brief where authorised | None through this workflow |
| Vendor support | No standing access by assumption | None by assumption | Time-bound support access only if approved | None |
The UK National Cyber Security Centre distinguishes authentication from authorisation and recommends minimum necessary access, deny by default and permission validation on each request. Its API guidance also covers secure credential handling and monitoring. Use these principles as buyer questions, then verify the actual controls and configuration.
Specify joiner, mover and leaver behaviour
A field map describes values. A lifecycle table describes change.
| Event | Expected behaviour | Failure to test |
|---|---|---|
| Joiner becomes eligible | Create one eligible roster entry after the agreed start condition | Event arrives twice |
| Employee changes team | Update the approved group from the effective date | Old and new groups both remain active |
| Manager changes | Update routing without exposing prior material to the new manager | Event arrives late or out of order |
| Employee leaves | Stop future invitations and apply the approved retention process | Leaver remains active after a failed run |
| Source correction | Replace the incorrect operational field and record reconciliation | Destination silently keeps the old value |
| Consent or participation choice changes | Apply the workflow's documented response | Choice is overwritten by the next roster load |
Do not invent behaviour when requirements conflict. Put the record in an exception state, notify the owner and keep the last known status visible for reconciliation.
Reconcile every exchange
For each run, record:
- source snapshot or event window;
- records offered, accepted, rejected and unchanged;
- records created, updated, disabled or quarantined;
- duplicate and out-of-order events;
- validation failures by reason;
- start and completion time;
- credential or endpoint used;
- owner who reviewed unresolved differences.
The March 2026 update to NIST's API protection guidance addresses pre-runtime and runtime controls and recommends monitoring API access with logs, metrics and traces. A buyer does not need to prescribe the vendor's entire architecture, but should require enough evidence to distinguish a healthy run, a partial failure and an unauthorised request.
Define an acceptable reconciliation outcome before launch. “The job ran successfully” is insufficient if three records were dropped without a visible exception.
A fictional integration test pack
Create records that exercise failure paths without using real employee data.
| Fictional case | Expected result |
|---|---|
| Valid eligible starter | Accepted once with the intended group and locale |
| Missing delivery address | Rejected or quarantined with a named reason |
| Duplicate worker ID | No duplicate invitation; conflict visible for review |
| Unknown location code | No guessed mapping; controlled exception |
| Team move effective tomorrow | Old group remains until the effective time, then changes once |
| Leaver event after roster load | Future invitation is stopped according to the approved rule |
| Same event delivered twice | One final state; duplicate recorded safely |
| Late earlier update | Newer valid state is not silently overwritten |
| Unauthorised field request | Denied and logged |
| Destination unavailable | Retry or recovery follows the documented process without duplicate writes |
Ask the vendor to run the pack in the proposed connection and configuration. A sample CSV proves file handling only. An API documentation page proves an interface is described, not that your tenant, scopes and workflow are ready.
Pilot readiness checklist
Do not start live exchange until the team can answer yes or not applicable to each item:
- Is the workflow and system-of-record boundary written?
- Does every transferred field have a purpose and owner?
- Are allowed values, transformations and effective dates documented?
- Are read, write, support and manager permissions tested separately?
- Are credentials scoped, stored, rotated and revoked through an owned process?
- Are transfer, validation and access events visible in logs?
- Do joiner, mover, leaver, correction and choice changes have expected behaviour?
- Can the team reconcile source and destination after a partial failure?
- Are retention, deletion and incident routes approved for this workflow?
- Has the fictional test pack passed in the proposed environment?
- Is rollback possible before any write-back is enabled?
- Does a named person have authority to pause the connection?
Record “not demonstrated” rather than converting a vendor answer into observed evidence.
Worked example: a mover arrives late
This example is fictional and does not describe a Lontra connector.
A UK services employer uses a scheduled approved file to provide campaign eligibility, work email, team code and locale. During the test, employee A moves from Team East to Team West. The HRIS effective date is Monday, but Friday's file already contains the new team. If accepted, the employee could be grouped with West before working there.
The data contract is revised so the destination stores the future change but applies it only at the effective time. The test pack then sends the same record twice and an older Team East record after Monday. The expected final state remains Team West, with the duplicate and stale update visible in reconciliation.
This test does not prove the whole integration is secure or correct. It verifies one lifecycle rule and exposes the evidence the operations owner needs before a limited live pilot.
Where Lontra fits
Lontra's product approach supports focused employee conversations and manager briefs for human follow-up. Managers receive a brief rather than raw employee conversations, and the platform is not an HRIS or an individual scoring system.
This article does not claim a particular Lontra HRIS connector, API, write-back, SSO or identity-sync capability. Verify the exact import, export, authentication and integration options for the intended account and deployment. A manual or controlled file workflow may be the correct pilot design when it meets the approved purpose and controls.
Frequently asked questions
What should an HRIS and AI integration include?
It needs a defined purpose, minimum field map, source ownership, access rules, transfer method, validation, reconciliation, lifecycle events, correction and deletion handling, monitoring, and a named response when the exchange fails.
Does an AI HR product need to write data back to the HRIS?
No. A read-only file or controlled import may be sufficient for a pilot. Write-back adds operational and data-quality risks, so require a specific destination, owner, validation rule and rollback process before enabling it.
How should HR test an integration before using employee data?
Use fictional records that include missing values, duplicates, invalid codes, a manager move, a leaver, a late update and an unauthorised request. Reconcile every accepted, rejected and changed record before a limited live pilot.
Does Lontra offer a connector for every HRIS?
This guide makes no connector claim. Buyers should verify the exact import, export, API, identity and authentication options available for their account and proposed deployment before choosing an architecture.