How to Automate Employee Onboarding and Offboarding with SmartHR and Jinba

Summary

Japanese offboarding deadlines make manual access revocation a compliance risk: Employment Insurance loss filing must be submitted within 10 days of the day after departure, and Social Insurance loss filing within 5 days of departure.
The core automation pattern is trigger, enrich, route, log: SmartHR triggers the workflow, Microsoft Entra ID adds organisational context, notifications and deprovisioning reach the right teams, and the Operation Log records every step.
SmartHR API pagination must be handled across all pages; reading only the first page can miss departing employees without detection and leave accounts active.
Microsoft Graph requires the User.Read.All scope, not User.ReadBasic.All; otherwise department and companyName fields are empty and routing fails.
Start with the new-hire IT notification flow, then extend to manager notifications, Entra ID enrichment, and offboarding; Jinba Flow provides the audit-ready orchestration layer.

Manual provisioning across GitHub, AWS, Slack, and Google Workspace represents a significant operational cost. Each new hire requires someone to touch multiple admin consoles, and each departing employee requires the same effort in reverse, under tighter time pressure. When headcount grows, this does not scale. IT teams become the bottleneck for every hire and departure.

The underlying problem is coordination. Provisioning access to SaaS platforms requires a layer that speaks the API language of all connected systems simultaneously, pulling employee records from the HRIS, resolving organisational context from the directory, and routing tasks to the right teams without a human in the middle. For HR and IT teams at Japanese enterprises using SmartHR, Jinba provides that orchestration layer.

This guide describes the complete workflow: triggering automation from SmartHR events, enriching those events with Microsoft Entra ID data, routing notifications and provisioning tasks, and maintaining a full audit trail.

Why Japanese Enterprises Face Additional Offboarding Pressure

Offboarding carries statutory deadlines in Japan that make delayed processing a compliance failure, not just an operational inconvenience.

According to SmartHR's HR procedures guide, two filings must be submitted promptly after an employee departs:

Employment Insurance loss filing (雇用保険被保険者資格喪失届): Must be submitted within 10 days of the day after the employee's departure date.
Social Insurance (health and pension) loss filing: Must be submitted within 5 days of departure.

Beyond regulatory filings, offboarding requires collecting company assets such as laptops, ID cards (社員証), and access keys, and issuing statutory documents including the separation certificate (離職票) and withholding slip (源泉徴収票). When this process depends on manual handoffs between HR, IT, and line managers, delays are structurally guaranteed.

Automating the trigger ensures that access revocation and task notifications begin the moment a departure is recorded in SmartHR, not when someone remembers to action the ticket.

The Automation Framework: Trigger, Enrich, Route, Log

Every workflow in Jinba for HR lifecycle events follows the same four-stage structure:

Trigger: A SmartHR event, such as a new hire record, a transfer, or a departure flag, initiates the workflow.
Enrich: Jinba queries Microsoft Entra ID via Microsoft Graph to retrieve the employee's manager, department, and organisational context.
Route: Based on the enriched data, Jinba sends targeted notifications to Slack or Chatwork channels, creates IT tickets, and executes provisioning or deprovisioning actions.
Log: Every step is recorded in Jinba's Operation Log, producing a tamper-evident audit trail for compliance review.

This structure solves the fragmentation problem. Each team receives the specific information relevant to their role, derived from a single authoritative source, without HR or IT manually forwarding details between systems.

Building the Onboarding Workflow

Prerequisites

Before building the flow in Jinba, ensure the following credentials are available:

SmartHR: An API access token and the company's tenant subdomain (e.g., example.smarthr.jp). The token requires crew read/write and invite scopes. Store it in Jinba workspace secrets as a SmartHR Access Token credential. Full credential setup is documented on the Jinba SmartHR credentials page.
Microsoft Entra ID: A Microsoft Graph OAuth token with delegated User.Read.All permission. Tenant admin consent is required.
Slack or Chatwork: A Bot User OAuth token, created at api.slack.com/apps and stored in Jinba secrets as SLACK_BOT_TOKEN. Jinba's Slack integration is documented here.

Step 1: Configure the SmartHR Trigger

Use a scheduled trigger in Jinba to run the SmartHR list employees action at a defined interval. Configure it with the tenant subdomain and the stored credential. The SmartHR tool in Jinba also supports create, update, and invite actions, covering the full employee lifecycle from a single integration.

SmartHR's list API uses pagination via page (1-based) and per_page (default 10, maximum 100) parameters, with a Link header indicating subsequent pages. A workflow that reads only the first page of results will miss employees without detection when the result set exceeds the page size. The workflow must iterate through all pages before proceeding to avoid processing gaps, particularly on offboarding runs where a missed record means an account remains active after departure.

Step 2: Enrich with Microsoft Entra ID

This step enables role-specific and team-specific routing. Because each employee's provisioning requirements depend on their department and reporting line, the workflow must resolve that context from the directory before it can route tasks correctly.

The Jinba Microsoft Users tool provides two chained actions:

MICROSOFT_GET_USERS: Resolves the new hire's email address to their full Entra ID profile, including displayName, mail, jobTitle, and department.
MICROSOFT_GET_MANAGER: Takes the userPrincipalName from the first result and returns the employee's direct manager profile.

Use Jinba's needs dependency to chain these actions so the manager lookup executes only after the profile is resolved.

One configuration detail matters here: the User.ReadBasic.All scope is not sufficient for this integration. That scope leaves the department and companyName fields empty in the API response, which breaks any routing logic that branches on department. The token must carry User.Read.All, and tenant admin consent is mandatory for that scope to be granted.

Step 3: Route Notifications and Provisioning Tasks

With the employee's department, job title, and manager confirmed, the workflow routes tasks to the correct destinations using Jinba's Slack integration (SLACK_POST_MESSAGE or SLACK_POST_BLOCKS_MESSAGE):

Post to the #it-support channel with the new hire's name, department, and job title so IT can provision the appropriate laptop configuration and software licences.
Send a direct message to the hiring manager identified in the Enrich step with a structured onboarding checklist.
Post a welcome message to the relevant team channel.

Jinba's tool catalogue extends beyond Slack and Chatwork. Google Calendar and Outlook Calendar are available for scheduling orientation sessions. Jira integration supports automatic IT ticket creation. Google Forms can be incorporated to collect role-specific information from the new hire before their start date.

At this stage, SmartHR automation operates as a full provisioning orchestration layer: each downstream action is parameterised with data drawn from SmartHR and resolved through Microsoft Entra ID integration, rather than entered manually.

Building the Offboarding Workflow

Step 1: Trigger on Departure Status

Configure the scheduled SmartHR trigger to filter for employees whose employment status has changed to departing or whose departure date falls within the current processing window. The same pagination rules for the list action apply here. Every page of results must be processed before the workflow considers the run complete.

Where a transfer rather than a departure is recorded, the workflow branches accordingly: updating department assignments, notifying the receiving manager, and adjusting access group memberships rather than initiating full deprovisioning.

Step 2: Route Deprovisioning and Asset Collection

Once a departure record is confirmed, the enriched manager and department data drives the routing:

Notify the IT channel to revoke access across connected systems, including Entra ID groups, Google Workspace, and any linked SaaS platforms.
Send the departing employee's direct manager a task list covering collection of the laptop, ID card (社員証), keys, and any other company property.
Use the SmartHR tool's remove-department-assignment action to update organisational records in SmartHR itself.

Because the workflow executes immediately when the SmartHR record is updated, access revocation begins within the same processing cycle as the departure event, rather than waiting for a manual ticket to be raised and acted upon. This directly addresses the statutory timeline pressure: the HR team has accurate, timestamped records of when deprovisioning was initiated, supporting the compliance filings that must follow within five to ten days.

Security and Governance: RBAC and Audit Logging

HR lifecycle workflows process some of the most sensitive data in an organisation. Jinba addresses this through two mechanisms documented in the Jinba Flow feature overview.

Role-Based Access Control (RBAC): Jinba applies a two-tier permission model. Role-based settings control which functions and data each user role can access within a workspace. Organisation-wide settings restrict which departments can configure integrations with external services. This means the team building the SmartHR offboarding flow does not automatically have access to financial or legal integrations in the same workspace.

Least privilege via OAuth scope selection: When connecting external tools, Jinba allows selection of specific OAuth scopes for each integration. A Slack connection configured only to send messages cannot read channel history. A Microsoft Graph connection scoped to User.Read.All cannot write to the directory. This is enforced at the connection level, not just by policy.

Operation Log: Jinba maintains a dedicated Operation Log screen that records every action taken within a workflow, including who triggered it, what data was accessed, and what external calls were made. Events such as reading employee records from SmartHR, sending messages, and executing provisioning actions are all captured. For HR teams subject to internal audit or regulatory review, this log functions as the primary evidence of process execution and timing.

What to Build First

The highest-value entry point is the IT notification flow for new hires. It is self-contained, immediately measurable, and removes the most common manual step: an HR team member forwarding new hire details to IT by email or Slack message.

Once that flow is running, extend it in sequence: add the manager notification, chain in the Entra ID manager lookup, then build the offboarding counterpart. Each stage is independently testable within Jinba before it touches production SmartHR records.

For teams ready to build, the Jinba SmartHR integration documentation and the Microsoft Users tool reference are the two starting points. The SmartHR API pagination behaviour is documented on the SmartHR developer portal and should be reviewed before any production deployment that processes more than ten employee records per run.

Frequently Asked Questions

How does Jinba automate SmartHR onboarding and offboarding?

Jinba uses a scheduled SmartHR trigger to fetch employee records, enriches each record with manager and department data from Microsoft Entra ID, and then routes role-specific notifications or provisioning tasks to tools such as Slack, Chatwork, Google Workspace, Jira, and Microsoft Entra ID. This removes the manual handoff between HR and IT and ensures each new hire or departure starts the correct workflow immediately.

What are the Japanese statutory deadlines for offboarding?

In Japan, employment insurance loss filings must be submitted within 10 days of the day after the employee's departure date, and social insurance loss filings must be submitted within 5 days of departure. Because Jinba triggers offboarding workflows as soon as the SmartHR departure record is updated, access revocation and asset collection tasks begin in the same processing cycle, supporting HR teams in meeting these deadlines.

Which Microsoft Graph permission is required for SmartHR and Entra ID automation?

Jinba requires a delegated Microsoft Graph OAuth token with the User.Read.All scope, not User.ReadBasic.All, because the basic scope leaves department and companyName fields empty. Tenant admin consent is required for this scope, and least-privilege scope selection in Jinba prevents the connection from having write access unless explicitly granted.

What is the trigger-enrich-route-log framework in Jinba?

The framework has four stages: a SmartHR event triggers the workflow; Jinba enriches the record with Microsoft Entra ID data; the workflow routes notifications and provisioning actions to the correct teams and tools; and every step is recorded in the Operation Log as an audit trail. This structure gives HR, IT, and managers role-specific information from a single source without manual forwarding.

How does Jinba handle SmartHR API pagination?

Jinba workflows must iterate through all SmartHR list API pages using the page and per_page parameters and the Link header before proceeding. Processing only the first page can miss employees without detection, which is especially risky during offboarding when a missed record means an account remains active after departure.

Can Jinba deprovision access in Microsoft Entra ID and Google Workspace?

Yes. Once a departure record is confirmed, Jinba can trigger deprovisioning actions across Microsoft Entra ID groups, Google Workspace, and linked SaaS platforms, and it also notifies IT teams to revoke access. The workflow can update SmartHR records, such as removing department assignments, as part of the same automated run.

How does Jinba support compliance and audit requirements for HR data?

Jinba combines role-based access control, least-privilege OAuth scopes, and a tamper-evident Operation Log. The Operation Log captures who triggered each workflow, what data was accessed, and what external calls were made, providing HR teams with timestamped evidence for internal audits and Japanese regulatory filings.

What is the best first workflow to automate with Jinba and SmartHR?

The highest-value starting point is the IT notification flow for new hires. It is self-contained, removes the most common manual step of forwarding new hire details to IT, and can be extended step by step to manager notifications, Microsoft Entra ID enrichment, and the offboarding counterpart.