A new starter waits four days for a laptop and a leaver keeps access for a month. Here is the model behind a tracker that fixes both, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
An onboarding and offboarding tracker is four parts: templates that generate the task list from the role, tasks owned by teams rather than a coordinator, dates anchored to the start or leave date, and completion evidence. Offboarding is the half that matters most and gets the least attention, because a missed onboarding task is a bad first week while a missed offboarding task is standing access for someone who left.
Joiners and leavers
12
Tasks due today
3
Overdue on a leave date
2
Starters this week
100%
Access removed on time
A. Mensah starts 14 September, J. Ortiz leaves 9 September
You run people operations or IT. You already have a checklist somewhere. What you want is for it to generate itself per role, land in the right queues, and produce proof that access was removed on the day.
What happens when someone joins, and what has to happen the day they leave.
Templates match on department, role, level, location and employment type. A senior engineer in Berlin and a sales hire in New York get different lists.
IT sees provisioning, facilities sees the desk, the manager sees the introductions. No coordinator forwarding step, because that step is where the four days go.
Everything is an offset from the start or leave date, so a shifted date reschedules the whole plan on its own.
What was actually granted, per system, which is what the offboarding list is later generated from.
Which account was disabled, when, and by whom. That record is what an access review asks for.
Daily, loudly, until it is done.
This is not a checklist with due dates. It is four parts, and the first one is what makes it scale past one team.
Task sets that assemble from attributes: role family, level, department, location, employment type, systems required. A senior engineer in Berlin and a sales hire in New York should not get the same list.
Each task assigned to the team that performs it, appearing in that team's queue directly. IT sees provisioning, facilities sees the desk, the manager sees the introductions.
Every task due at an offset from the start or leave date, positive or negative, so a date change moves the whole plan without anyone rebuilding it.
For security-relevant tasks, a record of what was done: which accounts were disabled, when, and by whom. A tick box is not evidence.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Templates matched on the person, not one checklist for everybody.
In this Helix project, build me an onboarding and offboarding tracker.
Start with templates rather than a checklist. Each task template has a
description, an owning team, a day offset relative to the start or leave
date, whether it blocks other tasks, whether it requires evidence, and
conditions saying when it applies.
Those conditions run over person attributes: department, role family,
level, location, employment type, and the systems the role needs. Adding a
person generates their task list by evaluating every template. Show me
which templates matched and which did not, so I can see why a list looks
the way it does.
Do not build one generic checklist. Every new starter would get irrelevant
tasks and miss real ones, and after two months people stop trusting it.
Make every due date an offset from the start or leave date, never a fixed
date. Start dates move constantly, and the whole plan should move with
them.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Removing the coordinator who forwards things.
Each task lands directly in the owning team's queue. No coordinator in the
middle forwarding requests, because that step is where the four days a new
starter waits for a laptop actually go.
Give each team a view of what is due today, what is overdue, and what is
coming in the next week, with the person and their start or leave date on
every row.
Support dependencies: a task can require another first. Show a blocked
task as blocked and on what, and notify the owner of the blocking task
rather than the blocked one.
Give the manager and the new starter their own view of progress, without
exposing tasks that are not theirs.
Escalate overdue tasks to the owning team's manager after a set period,
and escalate anything overdue on a leave date immediately.Generated from what was actually granted, with evidence required.
Now build offboarding properly, because a missed onboarding task is a bad
first week and a missed offboarding task is standing access for somebody
who has left.
Two modes: planned, where the leave date is known, and immediate, where
access goes today. Immediate skips scheduling and puts everything in the
queue now.
Keep an access inventory per person: every system they have access to, the
level, and the owning team. Populate it from the provisioning tasks during
onboarding, so the offboarding list is generated from what was actually
granted rather than from a standard list written two years ago.
Access removal tasks require evidence: which account was disabled or
deleted, when, and by whom. A tick box confirms somebody clicked
something. An access review asks what was actually removed.
And cover the tasks people forget: mailbox delegation, calendar handover,
document ownership, on-call rota removal, physical items returned.Worth knowing. Generating the leaver list from what was provisioned, rather than from a template, is the difference between a checklist and a control.
Reporting, and template versioning.
Report time to complete per task type, so I can see which step is the
bottleneck. It is usually one team and one task. Then completion rate by
team and month, and average days to full access removal after a leave
date.
Show me tasks routinely skipped or marked not applicable. That is a
template whose conditions need fixing, not a compliance problem.
Build the audit view: every person offboarded in a period with their
access removal evidence, exportable. This gets asked for and it should
take one click.
And version the templates, so changing one does not alter the task lists
of people already mid-onboarding. That is the most confusing bug this kind
of app can have.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Workday>. Read joiners, leavers and role changes, which is what generates
a task list without anybody remembering.
<Okta>. Create accounts on the way in, disable them on the way out, and
record the evidence that it happened.
<Jamf>. Assign and reclaim hardware, and confirm the laptop actually came
back.
<Slack>. Land each task in the owning team's queue rather than a
coordinator's inbox.
<Google Workspace admin>. Create and suspend accounts, set mailbox
delegation, and transfer document ownership on the way out.
<Gusto>. Read the payroll start and leave dates, which are sometimes the
only accurate ones.
<Jira>. Raise the provisioning tasks in the queue IT already works from.
<Zendesk>. Close or reassign anything the leaver still owns before their
access goes.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. This holds employee records and access inventories, so set Access Control before sharing: teams see their own queue, managers see their reports.
The provisioning half is the point. An offboarding list is only trustworthy if it was built from what was actually granted.
Workday
Read joiners, leavers and role changes, which is what generates a task list without anybody remembering.
Okta
Create accounts on the way in, disable them on the way out, and record the evidence that it happened.
Jamf
Assign and reclaim hardware, and confirm the laptop actually came back.
Slack
Land each task in the owning team's queue rather than a coordinator's inbox.
Google Workspace admin
Create and suspend accounts, set mailbox delegation, and transfer document ownership on the way out.
Gusto
Read the payroll start and leave dates, which are sometimes the only accurate ones.
Jira
Raise the provisioning tasks in the queue IT already works from.
Zendesk
Close or reassign anything the leaver still owns before their access goes.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working tracker. It holds employee data, drives account provisioning, and produces the evidence an access review asks for, so how it is run is the larger half.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Employee records and access inventories are sensitive. SSO means people sign in with their existing account, and access is scoped so a team sees its own queue and a manager sees their own reports.
App Security
Reading joiners and leavers from an HR system and checking accounts in the systems you provision needs real access. Granting it to the app rather than pasting keys into it means credentials can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
Generate the right list per role from attributes, route each task straight to the team that performs it, and move every due date automatically when a start date shifts. A shared checklist does none of those and depends on one person chasing.
Because the failure mode is different. A missed onboarding task means a bad first week. A missed offboarding task means someone who has left still has access to a system, which is a finding in any access review and a real risk in between.
From what was actually provisioned to that person, not from a standard list. Maintaining an access inventory populated by the onboarding tasks means the offboarding list matches reality instead of matching a document written two years ago.
A record of which account was disabled or deleted, when, and by whom. A tick box confirms someone clicked something. An access review asks what was actually removed, and only the detailed record answers it.
As offsets from the start or leave date, positive or negative, rather than fixed dates. A start date moving by a week then moves the whole plan automatically, which is the most common real-world event this kind of tool has to survive.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement calls are your template conditions and which tasks require evidence.
IT and Operations
Request access against a defined catalogue, route it to the system owner, grant it with an expiry, and produce the evidence an access review needs. Prompts to build it, and what it takes to run it.
IT and Operations
One record per device and licence, with an assignment history, a lifecycle, and a reconciliation against what your systems actually report. Prompts to build it, and what it takes to run it.
People
One record per role from request to filled, with approval, budget, and a status that finance, recruiting and the hiring manager all read the same way. Prompts to build it, and what it takes to run it.
People
Track who is away, but also who covers which responsibility, so leave approval considers coverage rather than just a balance. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.