---
title: Automate onboarding and offboarding with People Workflows
description: How to automate onboarding and offboarding with People Workflows, using the Start date, End date and Last working day triggers.
---

[Skip to content](https://help.siit.io/onboarding-offboarding-workflows#main-content)

[![Logo\_Siit\_Full\_White](https://help.siit.io/hs-fs/hubfs/Logo_Siit_Full_White.png?width=70&height=33&name=Logo_Siit_Full_White.png)](https://help.siit.io/?hsLang=en)

- [Help Center](https://help.siit.io/)
- [Docs](https://docs.siit.io/)
- [API reference](https://developer.siit.io/api-reference/authentication)
- [Changelog](https://www.siit.io/changelog)

Open main navigation

Close main navigation

- [Help Center](https://help.siit.io/)
- [Docs](https://docs.siit.io/)
- [API reference](https://developer.siit.io/api-reference/authentication)
- [Changelog](https://www.siit.io/changelog)

 How can we help?

- There are no suggestions because the search field is empty.

1. [Help center](https://help.siit.io/?hsLang=en)
2. [Automations and Workflows](https://help.siit.io/automations-and-workflows?hsLang=en)
3. [Use cases](https://help.siit.io/automations-and-workflows?hsLang=en#use-cases)

# Automate onboarding and offboarding with People Workflows

#### Overview

Employee onboarding and offboarding are critical moments for both IT and HR teams.  
Each event typically requires coordinating multiple actions across systems: granting or revoking app access, notifying stakeholders, and ensuring nothing is forgotten.

Without automation, these processes rely heavily on manual steps, follow-ups, and cross-team communication — making them time-consuming, error-prone, and hard to scale.

With **People Workflows**, Siit allows you to automate onboarding and offboarding flows **based on employee lifecycle events**, without requiring an employee request.  
Combined with **app access actions** (Okta, JumpCloud, or custom integrations), you can ensure that the right access is granted or revoked automatically — at the right time.

#### Why Use People Workflows for Onboarding & Offboarding?

Unlike request-based workflows, **People Workflows** are triggered by employee data events, such as:

- Start date
- End date
- Last working day

![](https://help.siit.io/hs-fs/hubfs/image-png-Sep-30-2026-02-20-08-6404-PM.png?width=670&height=458&name=image-png-Sep-30-2026-02-20-08-6404-PM.png)

This makes them ideal for lifecycle processes where:

- no employee action is required,
- timing is critical,
- actions must happen consistently for every employee.

Typical benefits include:

- Faster Day-1 readiness for new hires,
- Reduced security risks during offboarding,
- Clear ownership and auditability across IT and HR.

 

💡 With People workflows, you can easily decide if you want the action to takes place before or after the trigger depending on if you click on the "+" above or below of the trigger.

![](https://help.siit.io/hs-fs/hubfs/CleanShot%202026-01-14%20at%2000-54-40@2x-png.png?width=670&height=886&name=CleanShot%202026-01-14%20at%2000-54-40@2x-png.png)

**Catching up when an employee is added late**

When a step runs before the trigger date, you can choose how strictly Siit reads that delay:

- **Exactly**: the step runs only on the scheduled day. If that day has already passed, the step is skipped. This is the default.
- **Within**: the step also runs if the scheduled day has already passed, as long as the trigger date hasn't.

For example, a step set to run 14 days before the start date will be skipped with **Exactly** if the new hire only appears in your HRIS 3 days before their first day. With **Within**, it runs once the record syncs to Siit, so the laptop order, the account creation and the welcome message still go out on time.

You'll find this choice in the delay settings of each action placed before the trigger. Actions placed after the trigger don't have it. On the canvas, the label above each step shows which one you picked, for example **Within 7 days before**.

#### ![](https://help.siit.io/hs-fs/hubfs/image-png-Sep-30-2026-02-30-42-2939-PM.png?width=670&height=385&name=image-png-Sep-30-2026-02-30-42-2939-PM.png)

#### Step 1 — Create a New People Workflow

Go to **Settings → Workflows** and click **Create workflow**.

Choose a **People trigger** depending on your use case:

- **Start date** → for onboarding,
- **Last working day** → for offboarding steps that should happen the day the person stops working, like suspending accounts,
- **End date** → for offboarding steps that should wait until the contract ends, like archiving the profile.

This ensures the workflow starts automatically based on employee lifecycle data, without opening a request.

💡 **Last working day** and **End date** are two different dates on the People record. With a notice period or garden leave, someone can stop working weeks before their contract ends. Pick the trigger based on when each action needs to happen.

#### Step 2 — Add Conditions to Target the Right Population

Next, refine when the workflow should apply by adding conditions.

Common examples:

- Department = Engineering,
- Location = EMEA,
- Employment type = Employee (exclude contractors),
- Legal entity or job level,
- Leaving Type (offboarding only) = Voluntary, to separate resignations from dismissals.  
  - 
  
  - 
  
  -

You can also combine multiple conditions to tailor onboarding or offboarding flows per team, region, or role.

![](https://help.siit.io/hs-fs/hubfs/CleanShot%202026-01-14%20at%2000-45-45-gif.gif?width=670&height=485&name=CleanShot%202026-01-14%20at%2000-45-45-gif.gif)

Branching on Leaving Type means one offboarding workflow can cover every exit  
reason. A resignation and a dismissal can follow different paths from the same  
End date trigger, so you no longer need a separate workflow per reason.

⚠️ Leaving Type reads the value your HRIS sends, and those values are not  
standardised across HR systems. Before you set this condition on a live  
workflow, open a People profile for someone who has already left and check the  
exact value your HRIS provides. A condition set to a value your HRIS never sends  
will never match, and the workflow will not run.

#### Step 3 — Provision App Access Automatically (Onboarding)

Once the workflow is triggered, you can start provisioning access for the new hire.

### Option 1 — Using Okta or JumpCloud

Add an action such as:

- **Add user to a group**
- **Add user to an application**

You can:

- Select groups manually (e.g. `engineering_employees`),
- Or dynamically map them based on attributes like department or role.

This ensures that, on Day 1, employees automatically receive access to the tools they need.

### ![](https://help.siit.io/hs-fs/hubfs/CleanShot%202026-01-14%20at%2000-49-15-gif.gif?width=670&height=400&name=CleanShot%202026-01-14%20at%2000-49-15-gif.gif)

### Option 2 — Using a Custom Provider via Webhook

If you use another identity or access system (e.g. Google Workspace, Azure AD, internal tools):

- Add a **Custom Action (Webhook)**,
- Send employee attributes (email, department, start date, role) to your provider’s API.

This allows you to replicate the same automation even outside native integrations.

#### Step 4 — Notify Stakeholders and Coordinate Tasks

Beyond app access, onboarding/offboarding often involves communication and coordination.

You can add actions to:

- Send a welcome message to the employee via Slack, Teams, or email,
- Notify the hiring manager that onboarding is complete,
- Notify IT or HR teams that access has been provisioned,
- Create tasks or issues in tools like Jira or Linear.

All actions are driven from the same workflow, ensuring consistency and traceability.

#### ![](https://help.siit.io/hs-fs/hubfs/CleanShot%202026-01-14%20at%2000-56-39@2x-png.png?width=670&height=394&name=CleanShot%202026-01-14%20at%2000-56-39@2x-png.png)

#### Step 5 — Automate Access Removal (Offboarding)

For offboarding, the same People Workflow logic applies — but in reverse.

Using the **Last working day** or **End date** trigger, you can:

- Remove users from app groups,
- Revoke active sessions,
- Deactivate or suspend accounts,
- Trigger equipment collection workflows,
- Notify managers and HR once access is fully revoked.

This significantly reduces security risks and ensures no access remains active after departure.

You can also split offboarding across both dates. For example, one workflow on **Last working day** suspends accounts and revokes sessions, and a second one on **End date** archives the profile and notifies HR. Your existing End date workflows keep running as they are.

 

#### Few Examples

![](https://help.siit.io/hs-fs/hubfs/CleanShot%202026-01-14%20at%2001-01-05@2x-png.png?width=670&height=463&name=CleanShot%202026-01-14%20at%2001-01-05@2x-png.png)

#### ![](https://help.siit.io/hs-fs/hubfs/CleanShot%202026-01-14%20at%2001-02-12@2x-png.png?width=670&height=457&name=CleanShot%202026-01-14%20at%2001-02-12@2x-png.png)

#### ![](https://help.siit.io/hs-fs/hubfs/CleanShot%202026-01-14%20at%2001-04-06@2x-png.png?width=670&height=390&name=CleanShot%202026-01-14%20at%2001-04-06@2x-png.png)

#### Final Result

With a properly configured People Workflow, you achieve a fully automated onboarding or offboarding flow:

- The workflow triggers automatically from employee lifecycle data,
- App access is provisioned or revoked without manual intervention,
- Stakeholders are informed at the right moments,
- All actions are traceable and consistent across the organization.

 

#### Frequently asked questions

**Should I use End date or Last working day for offboarding?**  
It depends on your offboarding policy. Last working day closes access as soon as the person stops working. End date keeps access open until the contract ends. Many teams use both: security actions on the last working day, admin tasks on the end date.

**My Last working day workflow didn't run. Why?**  
The trigger only fires for people whose People record has a last working day. Open the profile of someone who is leaving and check that the date is filled in. If it's empty, map the field from your HRIS in **Settings → Context management → People fields**.

**If a person has no last working day, does the workflow use the end date instead?**  
No. There's no fallback between the two triggers. If you want every departure covered, keep an End date workflow in place as well.

**A new hire was added late to our HRIS and missed their onboarding steps. What can I do?**  
Open each step scheduled before the start date and switch its delay from **Exactly** to **Within**. Steps set to Within catch up as long as the start date hasn't passed. Existing workflows stay on Exactly until you change them.

**Can a step set to Within run after the start date?**  
No. Within stops on the trigger date. If the employee record arrives after their start date, steps planned before it won't run in either mode.

**When should I keep Exactly?**  
For steps that only make sense on their own day, like a reminder meant to land exactly one week before someone's first day. For onboarding and offboarding tasks that must happen no matter what, use Within.

- [Getting started](https://help.siit.io/getting-started?hsLang=en#main-content)

    - [For Admins](https://help.siit.io/getting-started?hsLang=en#for-admins)
    - [Employee Guides](https://help.siit.io/getting-started?hsLang=en#employee-guides)
- [Request and Service Management](https://help.siit.io/request-and-service-management?hsLang=en#main-content)

    - [Request](https://help.siit.io/request-and-service-management?hsLang=en#request)
    - [Email](https://help.siit.io/request-and-service-management?hsLang=en#email)
    - [Service catalog](https://help.siit.io/request-and-service-management?hsLang=en#service-catalog)
    - [SLAs](https://help.siit.io/request-and-service-management?hsLang=en#slas)
    - [App access](https://help.siit.io/request-and-service-management?hsLang=en#app-access)
- [AI & Agents](https://help.siit.io/ai-agents?hsLang=en#main-content)

    - [Overview](https://help.siit.io/ai-agents?hsLang=en#overview)
    - [Setup](https://help.siit.io/ai-agents?hsLang=en#setup)
    - [Use cases](https://help.siit.io/ai-agents?hsLang=en#use-cases)
- [Automations and Workflows](https://help.siit.io/automations-and-workflows?hsLang=en#main-content)

    - [Getting started](https://help.siit.io/automations-and-workflows?hsLang=en#getting-started)
    - [Use cases](https://help.siit.io/automations-and-workflows?hsLang=en#use-cases)
    - [Integrations](https://help.siit.io/automations-and-workflows?hsLang=en#integrations)
- [Reporting and Analytics](https://help.siit.io/reporting-and-analytics?hsLang=en)
- [Integrations](https://help.siit.io/integrations?hsLang=en#main-content)

    - [Communication](https://help.siit.io/integrations?hsLang=en#communication)
    - [HRIS](https://help.siit.io/integrations?hsLang=en#hris)
    - [Ticketing](https://help.siit.io/integrations?hsLang=en#ticketing)
    - [Knowledge base](https://help.siit.io/integrations?hsLang=en#knowledge-base)
    - [Identity Provider](https://help.siit.io/integrations?hsLang=en#identity-provider)
    - [Device Management](https://help.siit.io/integrations?hsLang=en#device-management)
- [Knowledge Base Management](https://help.siit.io/knowledge-base-management?hsLang=en)
- [Admin, Security & Workspace](https://help.siit.io/admin-security-workspace?hsLang=en#main-content)

    - [Workspace Settings](https://help.siit.io/admin-security-workspace?hsLang=en#workspace-settings)
    - [SSO (SAML)](https://help.siit.io/admin-security-workspace?hsLang=en#sso-saml)
    - [SCIM & Provisioning](https://help.siit.io/admin-security-workspace?hsLang=en#scim-provisioning)
    - [People & Directory](https://help.siit.io/admin-security-workspace?hsLang=en#people-directory)

[![Siit\_Logo\_Dark](https://help.siit.io/hs-fs/hubfs/Siit_Logo_Dark.png?width=140&height=67&name=Siit_Logo_Dark.png "Siit_Logo_Dark")](http://siit.io)

<https://www.linkedin.com/company/siit-app>

Copyright © 2025, Siit SAS