Offboarding Reference Public

Daily Operations

Day-to-day guide to running offboarding cases in ERPat: start a case, work the checklist, assets, access actions and sign-offs, then reach final clearance, hold, reschedule, or immediate separation.

Guide version: r1 Module version: 1.1.0 Updated: 2026-07-22 Estimated time: 6 min 1 views
Operations

Daily Operations

Everything an operator does after setup: open a case, work the five case tabs, record asset and access outcomes, handle sign-offs, manage the case lifecycle (hold, reschedule, cancel, reopen), reach final clearance, and — where authorized — run an immediate separation.

Starting a case

From Offboarding → Checklist, click Start case. You are asked for:

FieldNotes
EmployeeThe departing staff user, chosen from the Employee Master.
Separation typeVoluntary Resignation, Immediate Separation, End of Contract, Retirement, or a tenant-defined type. It drives which template is used.
Last working day + execution timeThe anchor date/time all task and action due dates are calculated from.
Case ownerThe person accountable for the case. Defaults to you; can be reassigned.
TemplateAuto-resolved from the separation type's published template. You can override it with another published template if your rules allow.
VisibilityStandard or Confidential. Confidential cases restrict who can read the reason and details.
Initiation noteOptional context recorded on the case at start.
????
Preview before you start. The start dialog previews the tasks, assets, access actions, and sign-offs that will be created, and shows which template rule matched. Review it, then confirm.
⚠️
Duplicate active cases are blocked. If the employee already has an open offboarding case, the module prevents a second one, so a departure is never tracked twice.

The case page — five tabs

1 · Checklist

All tasks for the case, grouped by section (handover, IT, facilities, finance, …). Each task shows its owner, due date, and status.

2 · Assets

Company assets endorsed to the leaver, pulled from the Asset Registry, each awaiting a recorded outcome.

3 · Access

Account and access actions (disable accounts, revoke groups/licenses, transfer data ownership) scheduled to the departure.

4 · Sign-offs

Department sign-off requests and their approve/reject state, plus the final clearance gate.

5 · Audit

The immutable activity log — every start, change, outcome, sign-off, hold, and closure with who and when.

Completing checklist tasks

Open a task from the Checklist tab and mark it complete. Two rules govern completion:

  • Evidence-required tasks need a completion note (and, where configured, a reference or file) before they can be marked done — the system will not accept a bare completion.
  • Dependency-blocked tasks stay blocked until every task they depend on is complete. You cannot complete a task ahead of its prerequisites.

Task ownership comes from the template rule — the reporting manager (resolved from the department head), the case owner, or a specifically named user. If an employee has no department head, the reporting-manager task falls back to the case owner so it never becomes ownerless.

Recording asset outcomes

On the Assets tab, record an outcome for each item endorsed to the leaver:

OutcomeMeaningRules
ReturnedAsset handed back.Record condition; evidence per settings.
TransferredReassigned to another holder.Record condition and where it went.
LostCannot be located.Raises a clearance exception (pending).
DamagedReturned unusable.Raises a clearance exception (pending).
WaivedReturn not required.Recorded with justification.
????
A lost or damaged asset creates a pending exception that will block clearance. Resolving it — waiving the exception — requires the offboarding_clearance permission, so a controlled approver decides. Recording asset outcomes needs offboarding_assets.

Access actions

Account and access actions on the Access tab move through a clear lifecycle so nothing is revoked early and nothing is missed:

Scheduled
Planned to the last day
Awaiting verification
Due — needs an operator
Completed
Verified done

The scheduler moves an action to awaiting verification at its planned time. An operator with offboarding_actions then marks it completed or failed. A failed action can be retried — it returns to awaiting verification for another attempt.

????️
External connectors run in manual-verification mode in this version. The module does not make an outbound call to Microsoft Entra ID, Google Workspace, SCIM, or a webhook — instead it prompts an operator to perform the change in the provider and confirm it here, and the confirmation is audited.

Sign-offs

Department sign-offs are requested on the Sign-offs tab. Each request is pending until its signatory acts:

  • The designated signatory, or any user with the offboarding_signoff permission, can decide a sign-off.
  • Approving advances the gate. Rejecting requires a note and returns the relevant work for rework.
  • Whether sign-offs are part of the closure gate is decided by Final Clearance — a sign-off's "final gate" flag in Setups determines if it must pass before the case can close.

Case lifecycle actions

Beyond working items, the case owner can move the whole case:

Hold / Resume Pause a case (for example, a disputed departure) and later resume it. Held cases stop progressing. Reschedule Change the last working day. Future task and action due dates rebase to the new date; completed work is preserved and the change is logged. Cancel Close a case that should not proceed (for example, the employee is staying). Cancelled cases keep their history. Reopen Bring a completed or cancelled case back into progress if something was missed.

Final clearance

Final clearance is a controlled state transition, not a checkbox. When you open the Final clearance dialog, the server calculates the current blockers and lists them precisely — incomplete gate tasks, unresolved assets, unverified access actions, pending required sign-offs, or open exceptions.

????
Exception closure is deliberately restricted. Closing a case that still has open items requires the offboarding_clearance permission and an approver who is different from the case owner — no one can wave through their own case. The exception and its approver are recorded.

When the gates pass (or an authorized exception is approved), the case becomes completed / exception closed and drops out of the active queue.

Immediate separation

For a same-day, security-sensitive departure, an authorized user with offboarding_immediate can run an immediate separation. It differs from a normal case in three ways:

  • Permission-gated — only immediate-permission holders can initiate it.
  • Optional dual approval — when enabled in Setups, a different immediate-permission holder must confirm the draft before it proceeds, so no single person can act alone.
  • Actions execute at once — the containment/access actions run immediately rather than being scheduled to a future last day.
????️
Immediate cases are typically confidential: the reason and pre-notification timing are restricted to users with offboarding_confidential, while the authorized security actions remain executable and audited.

Where to go next

Was this guide helpful?

Report a content problem