Eight User and Permission Mistakes in EDGEBIC (and How to Fix Them)

User permission mistakes in software rarely announce themselves. Nothing breaks loudly: a button is missing for one person, a login fails for a reason nobody can name, or an audit request arrives and the answer is "it says admin did it." In EDGEBIC by User Solutions, the same eight mistakes account for most access-related support calls. Every one has a documented cause and a one-minute fix.

The model behind these behaviors is covered in EDGEBIC users and roles explained, and the setup steps in how to set up users and roles in EDGEBIC. This post is the failure list.

1. Everyone Signs In as the Administrator

Symptom. The audit trail shows one username doing everything. Nobody can answer who changed a schedule, and when a planner leaves, the only lever is changing a password the whole shop knows.

Cause. The founding administrator account was created on first launch and never replaced with named accounts.

Fix. Build two roles (Planner, Supervisor) and create one named account per person, with Must change password on next login ticked. Keep the founding admin account as a break-glass login stored in your password manager. The documented standard is blunt: one account per person, never shared logins, because the audit trail is only worth something if actions map to people.

There is a second cost that is easy to miss. Everyone on a shared admin login holds the two most destructive rights in the application: changing the database connection, and running the Clear Data Tables utility. Neither belongs in daily hands.

2. "Invalid Username or Password" When the Password Is Right

Symptom. A user is certain their password is correct and the sign-in dialog refuses it.

Cause. The account is deactivated, or it is locked after five consecutive failed attempts. The wording is identical in both cases, and identical again for a username that does not exist, because the message deliberately never reveals which is true.

Fix. An administrator opens Settings, then Security, then Users and reads the Active and Locked columns, then clicks Unlock or Activate / Deactivate. Unlock clears the lock immediately and resets the failed-attempt counter, so nobody waits out the 15-minute window.

Worth knowing: attempts made while an account is already locked do not extend the lockout. Somebody hammering the sign-in button is not making the wait longer.

3. A New Feature Works for the Admin and Not for Anyone Else

Symptom. After an upgrade, a new button or screen appears for the administrator and is invisible for planners and supervisors.

Cause. New permissions introduced by a product update are granted automatically to the built-in Administrator role only. Custom roles do not get them.

Fix. Edit each custom role and tick the new permission. This is a security-first default rather than an oversight: a capability that did not exist last month should not silently land in everyone's hands. Build the habit of reviewing custom roles after every upgrade.

4. Stripping Roles Instead of Deactivating

Symptom. A departed employee's account still signs in, showing an almost empty application.

Cause. Removing every role from a user does not deactivate them. They can still sign in; they simply hold no permissions.

Fix. Use Activate / Deactivate, which blocks the next sign-in attempt. Prefer it over Delete: the account's history stays intact and the username cannot be reused by accident.

5. Hunting for a Per-User Deny Checkbox

Symptom. An administrator spends an afternoon looking for a way to deny one permission to one person whose role otherwise grants it.

Cause. Permissions come through roles only. There is no per-user grant or deny override screen.

Fix. Create a narrower role and assign that instead. Name it so its scope is readable at a glance, for example "Planner without delete". The trade is real: a little more role maintenance, in exchange for access that is fully explainable from the role list with no hidden exceptions.

6. Reset to Default Turns Out to Clear Data

Symptom. Someone intends to reset a grid layout, works through a dialog, and rows are gone.

Cause. The toolbar's Reset to Default button opens the Clear Data Tables dialog, which resets saved screen layouts and can also permanently delete rows depending on what is ticked. It sits behind a red banner and a typed confirmation for good reason: there is no recycle bin.

Fix. Read the dialog and select only the intended scope. If all you want is layouts, choose the user-interface configuration scope only. And take an export first: one click on Export creates a timestamped backup next to the database file, safe even while the application is running. Withholding Settings permission from non-administrator roles removes this whole risk for most of your users.

7. Waiting for a Password Reset Email That Never Arrives

Symptom. A user clicks Forgot password and nothing lands in their inbox.

Cause. Self-service reset is not enabled in every installation, and where it is, it needs the license key and the email recorded on the account.

Fix. An administrator uses Reset password on the Users toolbar to set a temporary password, with Must change password on next login ticked so the person still ends up with a password only they know. That path always works and takes under a minute.

8. Trying to Delete Protected Records

Symptom. The Delete button refuses on the Administrator role or on the founding administrator account.

Cause. Both are protected system records, by design. Their protection is what guarantees an installation can never lock itself out.

Fix. Deactivate other accounts instead, and build custom roles alongside Administrator rather than trying to reshape it. If the founding account's credentials are widely known, reset its password and store the new one in your password manager.

Three More Worth Anticipating

Usernames cannot be changed after creation. Pick a convention before you create the first ten accounts (first initial plus surname is what most shops settle on) rather than discovering the constraint on account eleven. If a name genuinely has to change, create the new account, assign the same roles, and deactivate the old one.

There is no in-application viewer for the security audit trail yet. It records every security event permanently and it is append-only, but reading it is a query your administrator or support runs rather than a screen you open. Set that expectation before an audit rather than during one. Schedule changes are a different record entirely, tracked in the schedule change history shown with the job, which planners read directly.

Handing over administration is a task, not an assumption. When the person who set up the system leaves, three things need doing on the same day: reset the founding administrator's password and store the new one in your password manager, confirm a second named administrator exists, and check that the leaver's own account is deactivated rather than merely stripped of roles. Skipping any one of the three leaves either a shared secret in circulation or a system nobody can administer.

Making the First Review Easy

If you are inheriting an installation that has been running for a while, do the audit in this order rather than opening every account:

1. Sort the Users grid by last sign-in. Accounts that have never signed in, or have not signed in for months, are the first candidates for deactivation.
2. Read the Roles column. Anyone holding Administrator who is not an administrator is the finding that matters most.
3. Open each custom role once and check the Settings and Security sections are clear.
4. Count administrators. Two is right: one named person plus the founding account. Five means nobody decided.

Four steps, one screen, and it turns an inherited system into one you can describe.

The Pattern Behind the List

Read the eight back and two root causes cover almost all of them.

Convenience wins by default. A shared admin login is faster on day one than building roles, deleting is quicker than deactivating, and clicking through a confirmation dialog is faster than reading it. Every entry above is a place where the fast path costs something later, and none of them costs much to do properly the first time.

Silence is mistaken for absence. A permission that was never granted looks like a bug. A locked account looks like a wrong password. A capability that arrived in an upgrade looks like a licensing difference. Nothing errors out, so the interpretation people reach for is the wrong one. The cure is knowing that the smaller interface is usually a permission, and checking the role before opening a support case.

The Ten-Minute Access Review

Run this once a quarter and after every upgrade:

None of these takes longer than reading a grid. Skipping them is how a scheduling system quietly becomes something nobody can audit.

Where to Go Next

Read how EDGEBIC protects your schedule data for the mechanisms behind lockout, password storage, and the audit trail. Read deployment and database mistakes in EDGEBIC for the infrastructure equivalent of this list. The full administrator's journey is in the EDGEBIC admin guide, and broader troubleshooting sits in the EDGEBIC troubleshooting guide.

Bring your current user list to a demo of EDGEBIC, and we will turn it into a role design on the call.