Scheduling an Exit Before the Last Day
A login here can now be given an end date, and lapses on it with nobody having to remember. What took two controls to get there — and the one link still missing between the HR record and the account.
Offboarding is treated everywhere as a response: somebody leaves, and a list of things happens. The interesting question is why it is a response at all, when in a large proportion of cases the end date was known on the first day.
The two shapes of leaving
A permanent employee resigns, and the date is genuinely news. Nothing could have been scheduled, and a checklist triggered by the event is the right mechanism.
A contractor, a seasonal worker, an auditor, a consultant or a temporary cover has an end date agreed before they start. Nothing about that departure is news, and the checklist still runs on the day somebody notices.
Unplanned departure
- Date unknown in advance
- A response is the only option
- A checklist is the right tool
- Risk window is hours to days
Planned departure
- Date known on day one
- Could have been scheduled
- A checklist is the wrong tool
- Risk window is months to years
The accounts that stay live longest belong to the people whose leaving date was never in doubt.
What is built
The visibility half, and it is well done. There is a reconciliation screen listing every active login with no employee record behind it — sorted by dormancy, with never-used accounts first, each one deactivatable along with its sessions.
Three details in it are worth noticing, because each one is a decision somebody made rather than a default. It sits behind the permission to edit users rather than the permission to edit employees, because the accounts it surfaces may belong to administrators who were never in the HR system. Self-revocation is blocked, so nobody can lock themselves out of the screen they are using. And it is deliberately not automatic.
That last one is the important call. These accounts have no employment status to read, and an owner's account or an integration account is indistinguishable from a forgotten contractor to any rule you could write. So it is a list to review rather than a rule that runs — and the automatic version of this feature eventually deactivates the person who owns the business.
What shipped next
An end date. Since 2026-10-02 an account can be granted until a stated day: it stops working at the end of that day, any open session ends on its next click, and the mobile app is signed out. Three days before, the account holder and everyone who can edit users get a notice, so an extension happens before the lock rather than after it.
The difference between the two controls is the difference between finding a problem and not having one. A review screen makes a forgotten account visible to whoever looks; an expiry date makes a forgotten account impossible, because the forgetting no longer matters.
A six-month contractor, under each control
The gap between rows three and four is the entire argument, and it is measured in whatever your review discipline is rather than in days.
The detail found while building the screen
Worth recording because it generalises. The last-login timestamp on a user was stored without being declared as a date, so any attempt to format it or measure days from it failed outright — which is precisely what a dormancy-sorted list needs to do.
It had gone unnoticed because every other consumer of that column read it through a path that bypasses the declaration entirely. The bug existed for as long as the column had, and it surfaced the first time somebody tried to do arithmetic with it.
There is a related trap in reading that column at all, and it matters for anybody building a dormancy list of their own: an empty last-login value means the login was never tracked, not that the person never signed in. Sorting never-used accounts first is right; concluding that they were never used is not.
What AWRA OpsHub does today
- An access end date on any account, set when it is created or edited. Refused at sign-in from the end of that day, open sessions and mobile devices signed out, and the plan seat freed.
- One notice three days ahead of the end date, to the account holder and to everyone who can edit users.
- A leaver process with no opt-out: terminating or archiving an employee revokes the linked login whichever screen or import made the change, and a leaver's login is refused at sign-in even if it is switched back on.
- A reconciliation screen listing every active login with no employee record behind it, sorted by dormancy with never-used accounts first.
- Deactivation from that screen, terminating sessions, gated on the permission to edit users rather than employees.
- Self-revocation blocked, so nobody can lock themselves out of the screen.
- Employee offboarding as a process against the employee record.
- Audit logging that an administrator cannot delete.
More we can add to your workspace
- An automatic action on a dormant or unlinked account — deliberately.
- A reminder when a contract end date on an employee record passes.
- A link between a contract end date on an employee record and the account belonging to that person, so the HR date sets the account's end date by default.
- A scheduled review prompt for the reconciliation screen.
Where we point you to a specialist
- Declining to act automatically on unlinked accounts is a position we would defend rather than revisit. Any rule that tried would have to distinguish an owner's account from a forgotten contractor's, and neither carries an employment status to read.
- An empty last-login value means untracked rather than unused. Any conclusion drawn from a dormancy list has to carry that caveat, including ours.
- This is market-neutral. Latin America is here because contractor-heavy and seasonal engagement is an ordinary employment shape there, which is exactly where planned departures outnumber unplanned ones.
The link that makes the end date automatic
The end date on the account has shipped. What is left is the step that stops it depending on somebody remembering to set it at grant time.
The contract end date driving it
An employee record with a fixed-term end date setting the end date on the linked account by default. Today the end date is set on the account by whoever grants it, which is the same forgetting one step earlier.
A scheduled review prompt
A reminder to whoever owns access to open the reconciliation screen on a fixed rhythm, so the backstop is reviewed on a date rather than when somebody thinks of it.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If you engage contractors routinely, this is a small ask with a long tail of risk behind it.
Talk to us about account lifecycleFour questions about accounts and leavers
Can an account be granted until a date?
A good answer sounds like
Yes, with a warning first.
What it actually means
Ours can, with a notice three days ahead. It is the difference between a problem you find and a problem you do not have.
How do I find accounts nobody owns?
A good answer sounds like
A screen, reviewed regularly.
What it actually means
Ours has one. Ask whether it acts automatically, and be suspicious if the answer is yes.
What does an empty last-login mean?
A good answer sounds like
Untracked, possibly.
What it actually means
Most people read it as never used. Ours cannot support that reading and neither can most.
Does a contract end date do anything?
A good answer sounds like
It drives access.
What it actually means
If it is only a field on an HR record, the date is documentation rather than a control.
Our position
When you grant a contractor, an auditor or a temporary cover access, set the end date on the day you create the account — the date was agreed before they started, so it costs nothing to record. Then review the unlinked-accounts screen on a fixed day each month for the accounts nobody gave a date, because that review is still the only thing catching those.
Put the review in the calendar
A control that depends on somebody remembering needs a date, and the only reliable date is one in a calendar rather than in a policy.
Talk about access lifecycleFrequently asked questions
Does deactivating an account end its sessions?
Yes — deactivating a login, from the reconciliation screen or the users list, ends its web sessions, signs out the mobile app and stops a “keep me signed in” cookie working, which is the part that is often missed elsewhere and matters most in the hour after somebody leaves.
What happens when an account reaches its end date?
From the end of that day it is refused at sign-in, on the web and in the app, and any session still open ends on its next click. Within the hour it is also switched off on the users list, which frees its seat on your plan. To extend it, set a later end date and switch it back on.
Why is the screen behind the user-editing permission?
Because the accounts it lists may belong to administrators who were never in the HR system at all, so gating it on the permission to edit employees would hide exactly the accounts most worth reviewing.
Can I get a report of dormant accounts?
The reconciliation screen sorts by dormancy with never-used accounts first, which is the closest thing. Read it with the caveat that an empty last-login value means the login was never tracked rather than never used.
