Fluida offboarding automation: close Entra ID and Active Directory accounts on the termination date

Where the gap comes from

Fluida knows the termination date before anyone else does. IT hears about it through a ticket, a mail or a monthly list — if at all. Every day in between, a former employee keeps a working account, a licence and whatever the account could reach. Manual offboarding is not unsafe because people are careless; it is unsafe because it depends on someone remembering to start it.

How Joinly closes a leaver from Fluida

Joinly reads the termination date through the Fluida API (frequent sync, multiple times per day) and schedules the leaver workflow for that date. On the day, the steps run in order, and each one waits for the previous one to succeed:

• Disable the account in Entra ID and revoke every active session, so an open laptop is signed out too.
• In on-premise Active Directory, the Joinly AD Agent disables the account and can move it to a disabled-users OU.
• Remove group memberships — and with them the access that hung off those groups — and return the Microsoft 365 licences.
• Set an out-of-office, clear the calendar and convert the mailbox to a shared mailbox so the team keeps the correspondence.
• Remove SharePoint permissions and Teams memberships; raise an incident in TOPdesk or a request in Freshservice for the hardware.
• Days or weeks later, a threshold workflow archives or deletes the account and the identity.

What stops it from closing the wrong account

Someone with two contracts in Fluida is one person in Joinly, and the account is only disabled when the last active employment ends. Every import can run as a dry run first, with an Excel export of what would be deactivated. Thresholds cap how many deactivations one run may produce before it is blocked for approval, and an evaluation that would revoke more than 20% of assignments in one go stops itself — a broken HR export does not lock out half the organisation overnight.

When someone comes back

A returning employee is matched to the existing identity — on employee ID, person identifier or e-mail address — and the account is re-enabled with the access of the new position, not the old one. No second account, no inherited permissions.

The evidence afterwards

Each step lands in the audit log with its source and the workflow that caused it: when the account was disabled, which groups and licences were removed, which ticket was raised. That is the answer to the auditor's question — not "we have a process", but the record of the process having run.