Build Workelo

0%0 of 20 items done

Saved on this device only. Tick prerequisites first, then work the phases in order · do not start one until the checks above it pass.

Journey templates of tasks offset from a start or leaving date, launched per employee with owners assigned, reminders for overdue items, and an offboarding view that reports every outstanding access revocation by name and system until each is confirmed by the person responsible for it.

estimated effort weekendthe files for this build are in the project pack

RuntimeNode 22 with PostgreSQLDeploymentSelf-hosted and privateTimeDates rather than instants, with an explicit timezone for remindersEmailA transactional provider with a verified domainAuditAppend-only completion records with the confirming person

Before step 1

Everything below is assumed from the first step. Tick each one when you actually have it, not when you plan to.

installfree
Why Runs the application and the reminder job.
Get it nodejs.org, or nvm install 22. open ↗
Verify node --version prints v22 or higher
installfree
Why Journeys are relational and the audit trail is append only.
Get it Install locally or run it in Docker. open ↗
Verify psql connects and reports 16 or higher
have readyfree, and it usually takes longer than expected
Why Offboarding is only as good as this list, and the systems nobody remembers are exactly the ones that stay open. Assembling it is the most valuable part of this build.
Get it Ask every team what they administer. Include the small ones: a shared inbox, a design tool, a monitoring dashboard, a door code.
Verify The register exists with an owner per system
API keyfree tiers cover a small organisation
Why Reminders and the weekly report both depend on delivery, and internal mail that lands in spam is a task nobody does.
Get it Create an account, add the DNS records, take the credentials.
Verify A reminder arrives in an inbox and is not in spam
decidefree
Why This holds personal data including leaving dates, and how long you keep it is a decision with legal weight in most places.
Get it Decide per record kind with a reason. The security audit usually needs a longer period than the personal details, and separating them is the useful part.
Verify The policy is written with a reason per kind

Data model

Create these before the first phase that stores anything. Changing a table later is the expensive kind of change.

- employees(id, name, work_email, personal_email, role, manager_id, start_on, leaving_on, state)
- templates(id, name, kind, active) · kind is onboarding, crossboarding or offboarding
- template_tasks(id, template_id, title, description, offset_days, owner_role, category, requires_confirmation) · offset from the start or leaving date
- journeys(id, employee_id, template_id, anchor_date, launched_at, completed_at)
- tasks(id, journey_id, template_task_id, title, owner_id, due_on, state, completed_at, completed_by, confirmation_note)
- access_systems(id, name, owner_role, criticality) · what has to be revoked and who owns it
- audit(id, entity, entity_id, at, actor_id, action, detail_json) · append only, no update path
- A task marked requires_confirmation cannot be completed by the person it was assigned to without a note saying what they verified.

Environment variables

These go in a .env file the app reads at startup. The pack's .env.example is this table as a file · copy it, never commit the filled-in version.

Variable	Needed	Example	Where the value comes from
`DATABASE_URL`secret	required	`postgres://user:pass@localhost:5432/journeys`	Employee records and the audit trail. Personal data, kept private.
`PUBLIC_URL`	required	`https://onboarding.internal.example.com`	Internal only. Not publicly indexed.
`REMINDER_TIMEZONE`	required	`Europe/London`	When the daily reminder job runs. Task due dates are dates rather than instants.
`ESCALATE_AFTER_DAYS`	required	`3`	Overdue days before a task escalates to the manager.
`REVOCATION_ESCALATE_DAYS`	required	`1`	Shorter for access revocations, because an open account is a live risk.
`RETENTION_MONTHS_PERSONAL`	required	`24`	Personal details, per your written policy.
`RETENTION_MONTHS_AUDIT`	required	`84`	Revocation audit. Longer, because it is the security record.

The build, in order

1
Templates with offsets rather than dates
A journey template describes timing relative to a date, so it works for anyone.
1. Negative offsets for things due before a start date, which is most of onboarding.
  Files src/templates.js
2. Resolved at launch, recorded on the task. Named people on templates rot.
  Files src/roles.js
3. Rather than assigning to nobody, which is how tasks disappear.
  Files src/journeys.js
done when · tick each as it passes
watch out
- Putting a named person on a template means every template breaks when that person changes role, and nobody notices until a task is assigned to someone who left. Use roles on the template and resolve to a person at launch, recording who it resolved to.
next phase
2
Reminders that reach the right person
An overdue task produces exactly one clear reminder to whoever owns it.
1. One message with everything, rather than one per task.
  Files src/reminders.js
2. Not at queue time. Reminding someone about a task they just finished is the annoying failure.
  Files src/reminders.js
3. To the manager after a period. Repetition alone is ignored.
  Files src/escalation.js
done when · tick each as it passes
watch out
- Sending one email per overdue task means an owner with six overdue items gets six emails and ignores all of them. Batch per person per day, and escalate rather than repeating, because repetition without escalation is just noise.
next phase
3
Offboarding, and access that is verified
Every system someone had access to is revoked and confirmed by the person who owns it.
1. Name, owner role, criticality. This register is the thing that makes offboarding real.
  Files src/systems.js
2. From what the employee actually had, not from a generic list.
  Files src/offboarding.js
3. From the system owner. A tick from anyone else does not close it.
  Files src/tasks.js
done when · tick each as it passes
watch out
- A revocation task completed by whoever was closest to the checklist is the failure this exists to prevent, because they usually did not check. Require confirmation from the system owner with a note, and record who confirmed, because that name is what someone will want six months later.
next phase
4
The report nobody can ignore
Outstanding access revocations are impossible to miss.
1. Across all journeys, sorted by age and criticality. Not per journey.
  Files src/reports.js
2. The journey is not finished. Allowing it hides the problem.
  Files src/journeys.js
3. To someone accountable, with anything old escalated.
  Files src/reports.js
done when · tick each as it passes
watch out
- Letting an offboarding journey be marked complete with revocations outstanding removes the one signal that would have caught it, and the journey then looks finished in every summary. A journey completes when its revocations are confirmed, and not before.
next phase
5
Who can see what
Employee records are visible only to the people who need them.
1. Not in templates. Test with direct requests rather than through the interface.
  Files src/auth.js
2. A leaving date is not general information. Filter at the query.
  Files src/queries.js
3. Seeing everything is a permission worth recording the use of.
  Files src/audit.js
done when · tick each as it passes
watch out
- A leaving date visible to the whole company before it is announced is a real harm to the person leaving, and it leaks through task lists and reports rather than through a profile page. Restrict at the query, and check what a task list actually returns rather than what the interface displays.
6
Retention, export and the record you keepproduct builder
Employee data is kept as long as it should be and no longer.
1. Personal details and the security audit have different reasons and different periods.
  Files docs/retention.mdsrc/retention.js
2. Before it is requested. Assembling it by hand under time pressure produces an incomplete answer.
  Files src/sar.js
3. Including the audit trail, which is append only and must come back intact.
  Files scripts/backup.shREADME.md
done when · tick each as it passes
watch out
- Deleting an offboarding journey when its employee record expires destroys the evidence that access was revoked, which is the record you most need if something surfaces later. Separate the retention periods: personal details expire, the revocation audit persists in a form that does not identify the person more than necessary.

what this build does not replace

Automatic revocation through identity provider integration.
Payroll, benefits and human resources records.
Employment advice of any kind.
Mobile applications.
HRIS and ATS connectors, so employee records get typed in by hand
Automatic account and access provisioning in Google Workspace, Slack, and IT tools, plus the deprovisioning checklist on exit
E-signature and document collection flows that a legal team will accept
The polished employee-facing portal and email design that makes day one feel intentional rather than homemade
Reporting, audit logs, and the GDPR paperwork story your HR lead will ask about

after v1, if you want it

Identity provider integration for the systems that support it, keeping the checklist for those that do not
A quarterly access review, which uses the same register and catches what offboarding missed
Equipment tracking, since a returned laptop is the other thing nobody chases

Need the files? The project pack on the verdict page hands your agent the whole brief · more hr.