AWRA OpsHub Search

The Leaver You Cannot Schedule

A login here can be revoked and cannot be given an end date. So every contractor account depends on somebody remembering, on a day that has no reminder attached to it, months after the decision was made.

HR & Payroll AWRA OpsHub Team 12 min read

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 is not

An expiry date. An account cannot be granted until a stated day and left to lapse.

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

Account created Day 0
Engagement ends Day 180
With a review screen Day 180 + review cycle
With an expiry date Day 180
With neither Indefinite
What the review cycle actually is However often somebody remembers

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.

Account lifecycle, precisely

What AWRA OpsHub does today

  • 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.

What it does not do

  • Any account expiry date. A login cannot be granted until a stated day.
  • Any automatic action on a dormant or unlinked account — deliberately.
  • Any reminder that an engagement end date has passed.
  • Any link between a contract end date on an employee record and the account belonging to that person.
  • Any scheduled review prompt for the reconciliation screen.

Not ours, by choice

  • The decision not to act automatically on unlinked accounts is one we would defend rather than fix. No rule can distinguish an owner's account from a forgotten contractor's, because neither has 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.
  • Nothing here is Colombian, Brazilian, Chilean or Peruvian. 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.

What we would build

One control, and the link that makes it automatic

The gap file already names the first as the remaining half of a story whose other half shipped. The second is what stops it depending on somebody remembering at grant time.

An expiry date on an account

Granted until a stated day, then lapsed with no action by anybody, with a warning to the grantor before it happens. This turns the reconciliation screen from the control into a backstop, which is the right relationship between the two.

The contract end date driving it

An employee record with a fixed-term end date setting the expiry on the linked account by default. Otherwise the expiry depends on somebody choosing to set it at grant time, which is the same forgetting one step earlier.

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 lifecycle

Four 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 cannot. 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

Review the unlinked-accounts screen on a fixed day each month and treat it as a real control rather than a report — until an expiry date exists, that review is the only thing between you and a live login nobody owns. And when you grant a contractor access, write the end date somewhere that will nag you, because the system will not.

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 lifecycle

Frequently asked questions

Does deactivating an account end its sessions?

Yes — deactivation from the reconciliation screen terminates sessions as well as disabling the login, which is the part that is often missed elsewhere and matters most in the hour after somebody leaves.

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.

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center