Deactivating Users and Offboarding in EDGEBIC

Offboard someone from EDGEBIC by deactivating their account rather than deleting it: deactivation revokes access immediately while keeping their historical record attributable, so the audit trail and the schedule changes they made stay meaningful. In EDGEBIC by User Solutions the right way to remove a user is not to erase them. It is to switch off their access and leave their history in place, which is a one-screen action with an outsized payoff for traceability.

This post is the offboarding routine. For the full reference behind the controls here, read the EDGEBIC admin guide, and for the model these accounts sit in, see how role-based access protects the schedule. It names controls that live in the users and roles screen, never any internal path.

Deactivate, Do Not Delete

The single rule of EDGEBIC offboarding is to deactivate rather than delete. Both actions stop the person from signing in, so both revoke access. The difference is what happens to their history.

Deleting an account erases the person from the system, which sounds tidy but breaks the records that reference them. The security audit trail names whoever performed each action, and the schedule change log records who accepted each reschedule. If you delete a departed planner, the entries that pointed to them lose their subject. The trail still shows something happened; it can no longer cleanly say who.

Deactivating keeps the account and its history while switching off access. The person can no longer sign in or change anything, and every past entry that names them stays attributable to a real individual. For any plant that might ever face a compliance question or need to reconstruct a decision, that preserved attribution is worth far more than a shorter account list.

The Offboarding Steps

A clean offboarding is short.

1. Confirm coverage first. Make sure whoever is taking over the departing person's work has an account with the right role, so there is no gap in who can do the job. This is a users and roles action, and it is easier done before the departure than after.
2. Deactivate on the departure day. From the users and roles screen, deactivate the leaving person's account. Access ends immediately.
3. Do not delete. Leave the deactivated account in place so its history stays attributable.
4. Check for shared logins. Confirm no shared account was quietly standing in for the person, because a shared login is an offboarding problem that deactivation alone will not solve.

That is the whole routine. Notice what is not in it: there is no export of the departing person's jobs, no transfer of schedules between people. The schedules live in the shared database and belong to the plant, not to an individual, so a handover is an access change, not a data migration.

Why the Handover Is Not a Migration

It surprises some administrators that offboarding a planner does not involve moving their work anywhere. The reason is that EDGEBIC's data is centralized in the database, whether the local single-file database for a solo setup or a shared SQL Server database for a team. Jobs, schedules, and actuals sit there, shared by whoever has access.

So when one planner leaves and another takes over, the incoming planner simply opens the same live plan. Completed work is never moved by a reschedule, so the history the departing planner built stays fixed, and the not-yet-done work is just the current plan the new planner now drives. The handover is a change in who is responsible, not a transfer of files. This is one of the quiet advantages of a shared database over a pile of personal spreadsheets: nobody's work is trapped on nobody's machine.

The Shared-Login Trap

The one situation that complicates offboarding is a shared login, and it is worth calling out because it is common in plants that grew into their scheduling tool. When several people use one "planner" account, deactivating it during someone's departure locks out everyone else, and its audit entries never named an individual in the first place.

The fix is to untangle the shared login before anyone leaves. Create a personal account for each real person, assign each the role matching their job, and deactivate the shared login once everyone has moved over. From then on every action attributes to a real individual, the audit trail becomes meaningful, and future offboarding is a clean single-account deactivation. Doing this proactively, rather than during a departure, is the difference between a calm handover and a scramble. The account setup itself is covered in how to set up users and roles.

Offboarding as Part of Access Hygiene

Deactivation is really the end of an account's lifecycle that began at onboarding, and treating it as such keeps the whole system honest. Accounts are personal from creation, roles match jobs, and departures deactivate rather than delete. Follow that lifecycle and the audit trail stays attributable across every hire and departure, which is precisely what makes it worth having, as the schedule change log and audit trail explains.

For the roles that these accounts carry, read how role-based access protects the schedule, and for the broader context of who touches a live plan, see what production scheduling is. The full administrator reference is the EDGEBIC admin guide.