Automating Employee Onboarding and Offboarding IT Tasks

To automate employee onboarding and offboarding IT tasks, start each run from an event on the employee record and let the identity provider carry out the access changes. At arrival, the usual tasks are enabling or creating the account, adding baseline groups, assigning licenses and the department’s applications, and notifying the manager. At a role change, access is added and removed, and each removal needs its own timing. At departure, sign-in is disabled, refresh tokens are revoked, group memberships are removed and equipment is recovered. The trigger comes from the HR system or the identity provider: Microsoft Entra lifecycle workflows key on the hire and leave dates of the user record, Okta treats one profile source as the source of truth for identities, and service desk platforms such as Atomicwork and Serval start runs from a new-hire or termination record in the HRIS. Who is hired, when someone leaves and whether an account is deleted remain human decisions.

Which event starts each run, and from which system?

Microsoft’s onboarding and offboarding templates key each run on a user attribute. Their trigger type can be time-based, an attribute change or a group membership change.

For arrivals, keyed on EmployeeHireDate:

• Onboard pre-hire employee: seven days before, with the task Generate TAP And Send Email.
• Onboard new hire employee: on the day (or on createdDateTime), with Add User To Group, Enable User Account and Send Welcome Email.
• Post-Onboarding of an employee: seven days after, with Add User To Group and Add user to selected teams.

For departures, keyed on employeeLeaveDateTime:

• Pre-Offboarding of an employee: seven days before, with Remove user from selected groups and Remove user from selected Teams.
• Offboard an employee: on the last day, with Disable User Account, Remove user from all groups and Remove user from all Teams.
• Post-Offboarding of an employee: Remove all licenses for user, Remove user from all Teams and Delete User Account.

Microsoft places these workflows downstream of HR: “While HR provisioning manages the creation and attribute updates of user accounts, lifecycle workflows provide additional automation of tasks.” Okta describes the same division: HR creates the account on hire, and on departure “the responsible department (usually HR) initiates the automatic process to fully deprovision the user.”

Service desk platforms start from the HRIS side. Atomicwork’s Workday integration starts its lifecycle workflows through an employee sync that runs every 24 hours. Serval’s People Teams examples list “New employee detected in HRIS” and “Termination detected in HRIS” as triggers. Ravenna’s lifecycle playbook takes intake through a webhook the HRIS can POST to, an agent rule on a request channel, or a form. A trigger that depends on a sync inherits its cadence, so check it before relying on it for departures. Directory details are on the identity provider profile.

What does a departure remove, application by application?

Okta’s lifecycle page gives the shape for apps connected through its integrations: “the user account is deactivated in the Okta Universal Directory, access to Okta app integrations is removed, and their accounts are automatically deactivated in external apps. If manual deprovisioning of the user account for any app is required, admins receive a notice in their dashboard.”

Okta also documents that when a user is removed from a group that provided access to an app integration, the user “is automatically deprovisioned from those app integrations.” That holds for access that came through the group. It does not address an assignment made directly, and the evidence supports neither conclusion: that direct assignments stay live, or that they all disappear. Ravenna states that its entitlement-revocation flow covers recorded entitlements. Check separately what each product can discover and revoke directly in the target systems. Its playbook words the limit this way: “Access that was never recorded as an entitlement cannot be revoked by Ravenna,” and a manual entitlement marked deprovisioned is a Ravenna record, not a change in the target system. Siit’s app access page shows each person’s access origin on the application’s Active Users tab, so an admin can tell why someone has access before revoking it.

The direct-assignment question is settled application by application:

• Is the account disabled or deleted in the application, and by which mechanism: the directory’s deactivation, SCIM, or a manual task?
• Do sessions and tokens that the application issues itself outlive the directory account?
• Does the application hold local accounts or direct grants that no group ever touched?
• Who takes over the files, the mailbox and the data the account owned?

What changes for a role change, a return or an urgent departure?

The joiner, mover and leaver labels name templates; they do not partition the work. Microsoft’s task catalog files Add user to groups and Remove user from selected groups under Joiner, Leaver and Mover alike, Enable user account under Joiner and Leaver, and Revoke all refresh tokens for user under Leaver and Mover.

A role change has its own Microsoft templates: Employee group membership changes, Employee job profile change and an on-demand Real-time employee change. Their tasks remove all access package assignments, with a scheduled removal that defaults to 15 days, notify the manager and, for a job profile change, request a new access package. Okta describes the update flowing from the source of truth to the apps. A mover can require both additions and removals, whose timing must be designed separately.

A rehire or a return may require account creation or reactivation. Okta states that when an employee returns, for example after a leave, “reactivating the user in Okta Universal Directory also reactivates the user’s accounts in the external apps.” Reactivation assumes the earlier account still exists, and that is decided at departure.

An urgent departure does not wait for a date. Microsoft’s Real-time employee termination template is on-demand, and its default tasks are Remove user from all groups, Delete User Account and Remove user from all Teams; the tasks can be changed. An urgent departure needs an immediate revocation path. Account deletion requires a separate decision about retention, ownership transfer and recovery. The catalog keeps the pieces apart: Disable user account, Revoke all refresh tokens for user and Delete user are distinct tasks. Ravenna’s offboarding playbook makes the same split. It suspends the user rather than deleting, retains the account for a legal hold window, and notes that suspension is reversible while deletion “destroys the audit trail and any recovery path.” It also puts data transfer before group removal, since removing groups first can strip the access the transfer needs.

How do you automate app access requests between the two dates?

Siit documents App Access Policies, available on the Pro plan. The employee picks apps and a Role in Slack, Microsoft Teams or the portal, answers the Role’s questions and goes through its approval policy. Access is then provisioned by a manual app owner task, an add-to-group call on the identity provider, a direct add to the app instance, or a mixed two-step. A Role can skip approval for apps nobody would refuse.

Serval documents access policies with a maximum access length and automatic revocation, a business justification, and sequential approval steps whose approvers range from named users and quorum groups to the manager and app or role owners. An approver can shorten the requested duration, and a step that times out (30 days by default) ends the approval without granting access.

Which applications may skip approval, and which a workflow may clear without a person, is a scoping decision before it is a configuration one. It is worked through in scoping what an agent may do alone, and the sequencing of approval rounds in what autonomy means for an IT agent.

• 01

  Six Microsoft templates key on hire and leave dates

  Microsoft's default templates key on EmployeeHireDate and employeeLeaveDateTime, with offsets from seven days before to seven days after. The pre-hire run fires a week before the start date.

• 02

  Task categories overlap

  Microsoft files Add user to groups and Remove user from selected groups under Joiner, Leaver and Mover alike. The categories label templates; they do not split the work by event.

• 03

  Group removal carries group-granted access

  Okta documents automatic deprovisioning when a user leaves a group that provided an app. Access granted another way is outside that sentence and needs its own check.

• 04

  Mover removal defaults to 15 days

  Microsoft's Real-time employee change template removes access package assignments with a scheduled removal that defaults to 15 days.

• 05

  Suspend first, delete later

  Ravenna's offboarding playbook suspends the user rather than deleting, retains the account for a legal hold window, and notes that deletion destroys the audit trail and any recovery path.

• 06

  An expiry is scheduled on a timestamp

  Siit schedules deprovisioning against the exact expiration timestamp, not the start of that day. A queue can add a few minutes, and a manual task leaves the access open until the person in charge executes it.

When does an expiring access actually get removed?

A duration on a request adds a third trigger. Ravenna’s playbook states that access policy durations are counted from provisioning time, not request time. Serval’s pages do not say at what time of day its automatic revocation is scheduled, a question to put to the vendor. Siit’s page does: deprovisioning is scheduled “against that exact timestamp,” so a ten-day grant made at 15:47 “is scheduled for deprovisioning ten days later at 15:47, not at the start of that day.”

Scheduled is not the same as done, and both vendors say so. On Serval’s provisioning page, group-based access, removed from the IdP group at expiry, “depends on IdP sync (minutes to hours)”, and temporary manual access gets a removal task for a person to complete. On Siit’s page, automatic deprovisioning (removing from a group or from an app instance) goes through a queue, so the effective revocation can land a few minutes after the scheduled time. Manual deprovisioning opens a task at the scheduled time, and the access is revoked when the person in charge executes it. The mixed two-step does both. By default the removal mirrors the grant. Siit does not re-run the Approval Policy before deprovisioning: expiration is automatic and no one signs off on it. A Deprovision now action ends an access before its date but still runs the Role’s configured action, so a manual one is gone only once its task is done.

Where does the automation stop, and what stays a human decision?

The first boundary is upstream. Who is hired, into which department, under which manager, starting when: people decide these and type them in.

The second boundary is downstream. Some chains end in work only a person can finish: an app owner clears a manual deprovisioning task, an admin acts on Okta’s notice. Data handover is another: Ravenna collects the mailbox delegate and the files recipient through a manager form, and Serval’s offboarding examples include reassigning ownership of shared drives. Deletion comes after those decisions, not before.

Which vendors document HRIS- or identity-provider-triggered onboarding and offboarding?

Listed here: service desk vendors whose public pages, read for this guide, show how their onboarding or offboarding runs start from an HRIS or an identity provider and which access tasks those runs perform.

• Atlassian: Jira Service Management’s Workday automation page documents a Worker added or updated trigger for onboarding new hires, arrivals only; its Okta automation page lists Create user, Add user to a group and Suspend user, the last for offboarding.
• Console: its HR solutions page describes offboarding that deactivates accounts across Okta, Google and M365, revokes access and removes groups, started “from a single request or HRIS event”; it names no onboarding trigger.
• Freshworks: Freshservice’s Workday connector automates onboarding and offboarding from Workday worker records, and its Employee Offboarding module can create tickets for software access revoking.
• Harmony: its Workday integration page lists IT setup when new employees are added in Workday, and access revocation when they are terminated there.
• Ravenna: its lifecycle playbook, which states that Ravenna has no native HRIS hire or termination webhook, ranks first for onboarding and offboarding intake a webhook the HRIS can POST to; its offboarding playbook removes identity provider groups, revokes remaining entitlements and suspends the user.
• Risotto: its integrations page says Workday status changes trigger onboarding and offboarding workflows, and that Notion access is granted or removed based on employee status.
• Serval: its People Teams examples give “Termination detected in HRIS” as the trigger for access revocation across email, Slack, provisioned applications and the identity provider.
• Siit: its HRIS page documents Start date and End date triggers, with an end-date offboarding that revokes sessions and removes app access.