Field notes › Product
The worker who is on the books but off the tools
Every labour hire database has a category of person the software never planned for: still on your books, but not to be rostered. Seasonal crew between swings. Someone on long-term leave or workers compensation. A worker who has moved on, whose records you are required to keep for years after the last shift.
Most systems offer two options, and both are wrong. Leave them active, and they clutter every picker, get chased by every reminder, and sooner or later somebody rosters them by accident. Delete them, and you have thrown away shift history, certificate records and the audit trail you may need to produce for a client or a regulator years later.
What actually needs to happen
The behaviour you want is specific, and it is worth writing down before evaluating any system against it.
The person's records stay exactly as they are: certificates with their expiry dates, every shift they worked, notes, the lot. They stop appearing when you build a roster, so nobody picks them out of a list by mistake. They cannot be assigned to a shift even by a route that skips the picker, such as a client requesting them by name or an admin editing a shift directly. Reminder emails stop chasing them, because a suspended worker cannot act on a reminder about an expiring ticket and getting one is confusing. Their login stops working. And all of it is reversible with one button when they come back for the next swing.
The advisory check trap
There is a subtlety here that catches software out. In most systems the compliance check is advisory in some places and blocking in others, and the pickers do the real filtering. Filter an inactive worker out of the picker and you have solved 90 percent of it, which feels like solving it.
The other 10 percent is a client raising a request naming a specific person, or an admin editing an existing shift and swapping someone in from a different screen. If those paths only consult an advisory check, the inactive worker goes on the shift, and the one thing you were trying to prevent happens through the side door. The refusal has to live in the shift editor and the assign action themselves, not only in the list of names you are offered.
The billing consequence nobody mentions
Here is the part that turns a tidiness feature into a money feature. If your pricing is per user, or if it is stepped by user count as ours is, then a worker who cannot log in and cannot be rostered should not be counted.
In Mustr, setting someone inactive suspends their portal login, and the nightly count bills on active logins, so they drop out of your user total until you switch them back on. For a firm with a genuinely seasonal shape, that is not a rounding error. A crew of 140 that drops to 90 between seasons is the difference between two brackets.
It also removes a bad incentive. If keeping records costs money, offices start deleting people to save it, and then the records they were required to keep are gone. Nobody should have to choose between good record keeping and a smaller bill.
Inactive is not the same as deleted
Deleting an employee still has a place. Someone entered twice, a test record, a person who has asked for their data to be removed and whose records you are not required to retain. That is a genuine delete, and it should stay available and stay deliberate.
The distinction to hold onto is that inactive is a state of the relationship and deleted is a statement about the records. Most of the time you mean the first one, and most software only offers the second.
A short checklist for your own system
Whatever you use, test these five things with a real profile before you trust it.
Set someone inactive, then try to roster them from the shift editor. Try to roster them from a client request. Check whether the nightly reminder job still emails them about an expiring ticket. Check whether their login still works. Then set them active again and confirm nothing was lost.
If all five behave, your seasonal churn is a status change rather than a data-loss decision. If any of them fail, you will find out during the busiest week of the season, which is when everybody comes back at once.
More of what has landed recently is on the what's new page, and the pricing page explains how the user count works.