People & HR

How to offboard a departing employee as Small IT and ITOps Teams

People & HRFor Small IT and ITOps Teams2 apps12 steps~24 min to set up

When someone puts in their two weeks, you have a list of 40 things to do and no single system that knows about all of them. You're in Okta deprovisioning SSO apps, in Google Workspace suspending the account, pinging Slack admins to remove them from channels, emailing whoever owns the Salesforce license to reclaim it, checking if they had AWS IAM keys, and trying to remember whether they had a Zoom license or just used the free tier. Meanwhile HR is in their own world in Paylocity processing the final paycheck, and nobody has told you whether the last day is Friday or two weeks from Friday. The runbook is a Notion page nobody has touched in eight months. You're a two-person team supporting 300 people and offboarding is a 3-hour fire drill every single time.

Build this on Starch → See the apps used

People & HRFor Small IT and ITOps Teams2 apps12 steps~24 min to set up

Outcome

What you'll set up

A structured offboarding tracker that pulls the departing employee's active app access, open Jira tickets, and AWS IAM status into one place — so you have a real checklist, not a mental list

An automated notification chain that pings each app owner (Salesforce admin, Zoom admin, GitHub org owner) with their specific action item when HR marks someone as departing in Paylocity

A license-reclaim log that records every seat recovered, what it costs per month, and who confirmed the deprovisioning — so you can show finance what offboarding saves you

The Starch recipe

Apps, data, and prompts

The combination of Starch apps, the data sources they pull from, and the prompts you use to drive them.

Apps used

Knowledge Management Task Manager

Data sources & config

Starch connects to Okta and Jira from the integration catalog — the agent queries them live when the offboarding app runs. Starch syncs your Paylocity employee data on a schedule to detect departures. AWS is connected directly to Starch; IAM and Cost Explorer data is queried on demand. Slack is connected from the integration catalog for automated notifications. Notion is synced on a schedule to pull in any existing runbook content as the knowledge base seed.

Prompts to copy

Build me an offboarding orchestrator that takes a departing employee's name and last day, pulls their active app list from Okta, checks for open Jira tickets assigned to them, checks if they have any AWS IAM keys or access keys via AWS Cost Explorer, and generates a checklist of deprovisioning steps with an owner and due date for each one

Every time a new offboarding checklist is created, send a Slack message to each app owner with their specific action item and a due date of the employee's last day. If an item isn't marked done 24 hours before the last day, send a follow-up reminder automatically

After each offboarding is complete, log the recovered licenses to a running tracker — app name, monthly seat cost, date confirmed, who confirmed it — and show me a monthly total of what we've reclaimed

Run these in Starch → or paste them into your favorite agent

Walkthrough

Step-by-step

1 Connect Paylocity to Starch — Starch syncs your employee roster on a schedule and detects when a termination date is set. This is your trigger.

2 Connect Okta from Starch's integration catalog so the agent can query the departing employee's active app assignments live when an offboarding starts.

3 Connect Jira from Starch's integration catalog so the agent can pull all open tickets assigned to the departing employee and flag them for reassignment.

4 Connect AWS directly to Starch so the agent can check for active IAM users, access keys, or cost anomalies tied to that person's account on demand.

5 Connect Slack from Starch's integration catalog so the automation can message each app owner directly with their deprovisioning action item.

6 Tell Starch: 'Build me an offboarding checklist app — when a departure is detected in Paylocity, pull the employee's Okta app list, open Jira tickets, and AWS IAM status, and generate a checklist with one owner and one due date per item.'

7 Tell Starch: 'When a checklist is generated, send each item owner a Slack message with their specific task and the employee's last day as the deadline. If the item isn't marked complete 24 hours before the last day, send a reminder.'

8 For any app that isn't in Okta SSO — carrier portals, niche SaaS tools, anything web-based — tell Starch: 'Automate login to [tool] through the browser and remove the departing employee's account.' Starch handles this without needing an API.

9 Set up the license-reclaim log: tell Starch to record every confirmed deprovisioning with the app name, monthly seat cost, date, and confirming owner. Pull this into a dashboard showing monthly savings.

10 Sync your existing Notion offboarding runbook into Starch's Knowledge Management app so the checklist reflects your actual process — and so Starch can update the runbook automatically when new steps are added.

11 After the first two or three real offboardings, ask Starch: 'Which checklist items consistently finish late? Which app owners are slowest to confirm?' Use the answers to tighten SLAs.

12 At the end of each quarter, run: 'Show me every offboarding completed this quarter, total licenses reclaimed, total monthly savings recovered, and average time from departure trigger to full deprovisioning.' Send to your IT manager or finance lead.

See this running on Starch

Connect your tools, describe what you want, and the agent builds it. Closed beta is free.

Try it on Starch →

Worked example

April 2026 departure — Marcus Chen, Account Executive

Sample numbers from a real run

Salesforce Enterprise seat	150
Zoom Pro license	16
GitHub Enterprise seat	21
Okta SSO apps deprovisioned (14 apps)	0
AWS IAM access key revoked (1 key, $0 direct cost but security exposure closed)	0
Total monthly seat savings recovered	187

Marcus gives notice on a Tuesday with a last day of April 25th. Starch detects the termination date in Paylocity that evening and automatically kicks off the offboarding checklist. By Wednesday morning, you and your IT partner each have a Slack message: you've got the AWS and GitHub items, they've got Salesforce and Zoom. The agent queried Okta live and found 14 active SSO app assignments — those are listed in the checklist with 'deprovision via Okta' marked as a single step. It also found two open Jira tickets assigned to Marcus — those get flagged for the engineering manager to reassign. On April 24th, one item is still open: the Salesforce reclaim. The automation fires a reminder to the Salesforce admin at 9am. By end of day the seat is reclaimed. On April 25th, the offboarding is marked complete. The license log records $187/month recovered — $2,244 annualized — from a single departure. Across 12 departures last year at your headcount, that's roughly $26,900 in annual seat savings that was previously just leaking.

Measurement

How you'll know it's working

Time from departure trigger to full deprovisioning (target: under 24 hours for SSO apps, under 5 business days for all seats)

Checklist completion rate before last day (are items getting done before access lapses vs. after?)

Monthly license cost recovered per offboarding

Number of open IAM keys or orphaned cloud credentials caught per quarter

Percentage of offboarding tasks completed without manual IT follow-up (automation coverage rate)

Comparison

What this replaces

The other ways teams handle this today, and how the Starch version compares.

Okta Lifecycle Management alone

Handles SSO deprovisioning well, but doesn't touch non-SSO apps, AWS IAM keys, Jira ticket reassignment, or license cost tracking — you're still doing the rest manually.

Torii or BetterCloud (SaaS management)

Good for license discovery and some automated deprovisioning, but adds another tool with its own contract, doesn't build custom checklists per departure, and doesn't handle browser-only apps without an API.

Notion + manual checklist

Free and flexible, but purely passive — someone has to open it, update it, and chase owners themselves. Nothing is automated and nothing talks to Okta, Paylocity, or Slack.

Jira Service Management offboarding workflow

Works if your team lives in Jira, but requires ongoing workflow maintenance, doesn't pull live data from Okta or Paylocity, and any cross-system step still requires a human to do it and mark it done.

On Starch RECOMMENDED

One platform — knowledge management, task manager all running on connected data. Setup in plain English; numbers stay current via scheduled syncs and live agent queries.

Try it on Starch →

FAQ

Frequently asked questions

We use Okta but some apps aren't behind SSO — can Starch still handle deprovisioning for those?

Yes. For any web-based tool that isn't connected through Okta, Starch can automate deprovisioning directly through your browser — no API needed. You describe the steps ('log into [tool], go to users, remove this email address') and Starch's browser automation handles it. This is how you get to a real 100% checklist instead of one that stops at whatever Okta covers.

Does Starch actually connect to Paylocity, or do we have to trigger offboardings manually?

Starch syncs your Paylocity employee data on a schedule, so it can detect when a termination date is set and trigger the offboarding workflow automatically. You don't have to remember to start it. ADP is also a scheduled-sync provider if your payroll is there instead.

We're not SOC 2 certified — is Starch?

Not yet — Starch is not currently SOC 2 Type II certified. That's a real limit worth knowing if your security review requires it. It's on the roadmap.

What if the departing employee had AWS IAM credentials — can Starch catch that?

Yes. AWS is connected directly to Starch and the agent can query IAM and Cost Explorer on demand. You can build a step into the offboarding checklist that specifically checks for active IAM users or access keys tied to that person and flags them for revocation. This is one of the most commonly missed steps in manual offboarding and one of the higher-risk ones.

Can Starch replace our existing Jira Service Management offboarding ticket process?

Starch doesn't replace Jira — it connects to it from the integration catalog. The most practical setup is keeping your Jira tickets where they are and having Starch pull open assignments from the departing employee as one input to the offboarding checklist. You can also have Starch create or update Jira tickets as part of the workflow if your team tracks IT work there.

We have an offboarding runbook in Notion but nobody uses it. Can Starch fix that?

Starch syncs your Notion data on a schedule, so you can pull that runbook in as the seed for the offboarding app. From there, the checklist is generated automatically each time — nobody has to open Notion. And when a new step gets added to an offboarding, you can have Starch write it back to the Notion doc so the runbook actually stays current.

How does Starch notify app owners? We have a mix of people who check Slack and people who only check email.

Starch connects to both Slack and Gmail from the integration catalog, so you can send notifications through either or both. You can also send to specific channels (like #it-ops-alerts) rather than DMs if your team prefers visibility.