How does Joinly sync INAZ to Microsoft Entra ID?

Joinly reads each HR change in HR Inaz through the export or data channel your deployment provides and applies it to the matching Entra ID account automatically. INAZ holds the authoritative employee dossier, so it is the starting point for each identity action.

1. Joiner. HR completes the hire in HR Inaz. Joinly reads the new resource’s dossier and determines the role from attributes like department, job title and cost centre. It then creates the account in Entra ID, assigns the right licences and maps the person into the correct groups — timed to the start date recorded in INAZ.

2. Mover. When someone changes position, department or cost centre in INAZ, Joinly updates their group membership, permissions and licences to match. Access that no longer fits the new position is revoked, so permissions stay aligned with the actual job.

3. Leaver. On the end date recorded in INAZ, Joinly disables the Entra ID account automatically. There are no orphaned accounts left active after someone has left, and a soft-delete grace window lets you recover an account if a leaver is rehired.

Example: An Italian company with several legal entities hires a customer-service agent in HR Inaz with a start date next Monday, assigned to a cost centre in its Milan office. Joinly reads the dossier, waits until the start date, creates the Entra ID account, assigns an Office E3 licence and adds the agent to the IT-CustomerService group. When that agent later transfers to a different department, Joinly swaps the groups the same day and keeps the UPN stable.

What manual user management costs

Without automation, every account starts as an email from HR or a line in a spreadsheet exported from INAZ that IT works through by hand. Because there is no native INAZ-to-Entra connector, even a home-built file feed only copies attributes across — the part that actually decides access, role-to-group mapping and joiner/mover/leaver timing, still falls to people.

• Onboarding delays. New joiners wait for accounts, licences and group access while a request sits in a queue, losing productive days in their first week.

• Permissions that don’t keep up (privilege creep). When movers change position or cost centre, old access often stays attached, so people accumulate rights they no longer need.

• Forgotten offboarding. Accounts that aren’t disabled on time are both a security and audit risk, and unused licences keep costing money — especially when the only trigger is a manual note from HR.

Joinly vs. a native / file-based Entra provisioning setup

INAZ has no dedicated Entra connector, so the realistic baseline is Microsoft’s own file-based inbound provisioning or a middleware feed. Both can move attributes across, but they stop short of the part that actually decides access. Here’s how the two compare for an INAZ-driven setup.

Watch-outs when connecting INAZ to Microsoft Entra ID

A few INAZ-specific details decide whether this connection stays reliable at scale.

• No standard provisioning API. INAZ describes itself as ‘fully integrable’ and interfaces with common databases, but it does not publish a general-purpose provisioning API. Joinly connects on top of the export your instance exposes — a structured file / record path, a database feed or a middleware channel — and confirms the exact route during onboarding.

• Deployment fragmentation. The same INAZ product ships as an on-premise user licence, as SaaS/ASP/Cloud, or as a fully outsourced BPO service, and the data path differs in each. Joinly is built to read whichever channel your deployment provides rather than assuming a single fixed format.

• Mapping the organization chart and cost centres to Entra groups. The INAZ organization chart, function charts and cost centres don’t translate one-to-one to Entra ID groups. Joinly builds explicit mapping rules from those structures to the correct groups and licences, so role drives access rather than manual assignment.

• UPN format with duplicate names. When two employees share a name, a naive UPN rule produces collisions. Joinly applies custom transformation rules — a suffix, a cost-centre code or a controlled tiebreaker — so every UPN is unique and predictable from day one.

• Italian payroll fields. INAZ carries Italian-specific data such as CCNL contractual tables and the codice fiscale that you rarely want to push into Entra verbatim. Joinly maps only the attributes you need via Liquid templates, so the right fields land in the right place and the rest stay in INAZ.

Joinly handles each of these by default with custom mapping and transformation.

Always audit-ready

Every account action Joinly performs is logged: who was affected, when it happened, which access changed and which INAZ change triggered it. For NIS2 that matters directly: access can be traced back to an authorised HR source rather than an ad-hoc request. Joinly is ISO 27001 certified, runs in an EU data centre in Amsterdam, applies least-privilege by default, and is built to meet NIS2 and ISO 27001.

Example case

Picture a regional healthcare provider with around 2,600 employees across several sites in Italy, running HR Inaz as its HR core while identity provisioning never quite keeps up. There is no native INAZ-to-Entra connector, so a colleague exports a list from INAZ each week and IT works through it by hand — creating accounts, assigning licences, adding groups. With seasonal contracts and frequent internal transfers between wards and departments the list is always behind, and new clinical staff wait until day two or three for their account and access.

Connect INAZ to Microsoft Entra ID with Joinly and that work disappears. Joinly reads each HR change in HR Inaz at the source and acts on it automatically: new hires have their account, Office licence and group access ready on their start date, transfers between departments swap the right groups the same day, and leavers are disabled on their end date with a 30-day soft-delete grace window.

“We used to re-key an INAZ export into Entra every week and still fall behind. Now an account is simply ready on the start date, a transfer just swaps the access, and we can show the auditor exactly which INAZ change created every bit of access.” — Head of IT, regional healthcare provider

The outcome this setup is designed for: onboarding drops from days to zero touch, the weekly re-keying stops entirely, and the team can walk into its next NIS2 assessment with a complete, source-backed audit trail.