How Role-Based Access Protects the Schedule

Role-based access protects the schedule by limiting who can change what and recording who changed it: a permission is one atomic right, a role bundles permissions, a user holds roles, and every security-relevant action is written to an append-only audit trail. In EDGEBIC by User Solutions a planner sees and clicks only what their roles allow, so the controls that could disturb a trusted plan are simply absent for people who should not use them, and the actions that are allowed map to named accounts. This post explains how that model keeps a schedule dependable.

Access control is one part of the administrator's job. For the full reference, read the EDGEBIC admin guide, and for the concept on its own, see EDGEBIC users and roles explained. This post is about the why: how the model protects schedule integrity. It names controls that live in Settings, never any internal path.

The Model: Permission, Role, User

The access model has three deliberately simple pieces. A permission is one atomic right, such as viewing work centers, generating schedules, or deleting customers. A role is a named bundle of permissions, such as Planner or Shop Floor Supervisor. A user holds one or more roles. What a signed-in person can do is the union of their roles' permissions.

That union is the first protection. Because capabilities add up across roles and never subtract, access is predictable: assigning a second role can only grant more, so an administrator reasons about what a role includes rather than about how overlapping grants and denies might cancel. To give someone less, you assign a narrower role, not a per-user deny, because permissions come only through roles. There is no per-user override screen layering exceptions on top. Access is always explained by the roles a person holds, which keeps the model auditable in the plainest sense: you can read a user's roles and know exactly what they can do.

Two records are protected so the model cannot be locked out of itself. The founding administrator account and the built-in Administrator role cannot be deleted, and the Administrator role always holds every permission, including new ones added by product updates. That guarantees someone can always administer the system.

Hidden Controls, Not Just Disabled Ones

The protection is not a warning that fires after a bad click. Screens and buttons a user lacks permission for are hidden or refused, including the entire Settings area and the security screens themselves. A control that is not present cannot be triggered by accident, by muscle memory, or by curiosity.

This is what keeps a trusted schedule from drifting through untracked edits. Give shop floor leads a role that views the schedule and logs actuals but omits the permission to run the scheduler, and the regenerate control is simply not there for them. Their actuals still flow in, the plan still updates when a planner reschedules, but the authority to rebuild the schedule stays where it belongs. The same logic protects master data: a role without delete rights cannot remove a work center or a customer that a live plan depends on.

Least privilege is the guiding habit. Build roles that start narrow and add a specific permission when someone genuinely hits a wall, which is far easier than granting broadly and clawing rights back. A schedule is protected not by trusting everyone to be careful, but by ensuring the controls that matter are only in the hands that should hold them. Set this up in how to set up users and roles.

Accountability: The Audit Trail

Limiting access is half the protection; recording action is the other half. Every security-relevant event (sign-ins, failed attempts, lockouts, user and role changes, permission denials) is written permanently to an append-only audit trail inside the database. Append-only means entries are added, never edited or removed, so the record of who did what stands.

That record is why one account per person matters, and why shared logins undermine the whole model. The audit trail only means something when an action maps to an individual: a due-date change tied to a named account is accountability, while the same change under a shared "planner" login is a dead end. Deactivating a departed user rather than deleting the account preserves that history, so the trail stays complete even as people come and go.

One honest limit belongs here. There is no in-app screen to browse the audit trail yet. It exists as a record inside the database that an administrator or support queries when a compliance or forensic question arrives. So the trail is a durable record you can rely on after the fact, not a live dashboard you watch. Planning for that means keeping accounts one-per-person and knowing the record is there when you need it.

Two Behaviors That Come On From Day One

Two protections are active from first launch, before any role is built. Account lockout stops five consecutive wrong passwords from continuing: the account locks for fifteen minutes, and the error message never reveals whether the username exists, so a guesser learns nothing. An administrator can clear a lock immediately with the Unlock control. And the password policy requires, by default, at least eight characters with an uppercase letter, a lowercase letter, and a digit.

Neither is about the schedule directly, but both protect the accounts that the schedule's access model rests on. A compromised account is a bypass of every role you built, so the sign-in itself is part of the protection.

A Worked Example: Locking Down Reschedule Authority

Consider a plant where too many people could regenerate the schedule, and the plan kept shifting under the planners. The fix is entirely in the role model.

Build a Planner role that includes running the scheduler, editing jobs, and accepting optimizer proposals. Build a Supervisor role that includes viewing the schedule, logging actuals, and running reports, but omits the permission to run the scheduler and omits delete rights on master data. Assign planners the Planner role and floor leads the Supervisor role. Immediately, the regenerate control disappears for the leads: it is hidden, not merely discouraged. Actuals still flow from the floor, and the plan updates only when a planner reschedules.

Now suppose a lead genuinely needs to change a due date during a shift. Rather than handing them the Planner role, add just the due-date permission to the Supervisor role, or create a narrower role for the one person. Access grows by the specific right, not by a broad grant, and the audit trail records the due-date changes against that person's account from then on. The schedule is protected by exactly who can touch it, and every touch is accountable.

Role-based access is, in the end, two guarantees working together: the controls that can disturb a trusted plan are only in the right hands, and every action that is allowed maps to a person. For the wider deployment this sits inside, read planning a multi-user rollout, and for the full administrator reference, the EDGEBIC admin guide.