Deciding Who May Change the Schedule in EDGEBIC

Running the scheduler, drag-rescheduling on the Gantt, logging actuals, and editing actual dates are four separate rights in EDGEBIC, and deciding who holds which is the core access decision in a plant. In EDGEBIC by User Solutions they are granted independently through roles, so you can give a supervisor the ability to report reality without the ability to replan the plant. This post is how to make that split deliberately.

The mechanics of building roles are covered in how to set up users and roles. This post is the decision that comes first: which capabilities belong together, and what goes wrong when they are handed out as one lump.

Why This Is Not One Permission

Most people assume "can change the schedule" is a single switch. It is not, and the reason is that the four actions have different blast radii.

Running the scheduler replans every job that is not already complete. It is triggered for a reason (a new order, a breakdown, a priority change) but its effect is plant-wide. Completed work never moves, which is the guarantee that makes the button safe to press, but everything still ahead of the plant can and does.

Drag-rescheduling on the Gantt moves one bar. It is a manual override, and the model is override and warn rather than validate and reject: feasibility of a manual drag is on the planner, and the next scheduler run resolves it. Small radius, but the change persists until something replans it.

Logging actuals records what the floor did. It changes no future dates directly, but it changes what the next reschedule treats as done.

Editing actual dates corrects what was recorded. That moves the boundary between completed and remaining work, which is the boundary every reschedule plans around.

Grant them as one lump and you cannot express the ordinary plant rule, which is that many people report and few people plan.

The Split Most Plants Land On

The rows that generate the most argument are the two in the middle of the supervisor column. Give a supervisor the drag when they genuinely sequence their own area and the planner cannot see the detail they can. Withhold it when the pattern you are trying to stop is areas quietly rearranging the plan so their own queue looks clear. Because rights are the union of a person's roles, you can grant the drag to one experienced supervisor through a second role without changing what the others hold.

Keep Reporting Cheap

The most common access failure in a plant is not over-granting to planners. It is under-granting to everyone else, which pushes people onto a shared login.

A read-only role costs nothing and cannot damage anything: schedule viewing, order viewing, reports, and dashboards. Handing that to shift leads, quality, sales, and management removes the reason anybody borrows the planner's credentials. That matters because the security audit trail records sign-ins, user and role changes, and permission denials permanently, and every one of those entries is meaningless if two people use one account. There is no browsing screen for that trail in the application, which makes one-account-per-person the only thing keeping it usable at all.

Where the Permission Model Ends and the Display Setting Begins

Two adjacent controls confuse this decision, and it is worth naming both.

The scheduler's display configuration includes appointment permission checkboxes: allow drag, allow create, allow delete, allow resize, drag between resources. Those are per machine and per user, not per person's account, so they lock down a station rather than an identity. They are the right tool for a shop-floor terminal that should show the plan without moving it, and the wrong tool for enforcing who in the plant may replan. See how to limit who can edit the Gantt for that mechanic.

The optimizer is its own decision. Viewing, running, accepting, and configuring the optimizer are separate rights again, and accepting is the one that matters because it is the moment a proposal becomes the plan. Nothing changes until someone accepts, and the multi-run layer is guaranteed never to be worse than the baseline it started from. That split has its own post: who can run and accept optimizer changes.

Two Rules That Prevent Most Regret

Start narrow and widen on real walls. Adding a permission is a minute. Removing one from someone who has used it for a month is a conversation with their supervisor. Because access is additive, growing a role is always easier than shrinking it.

Review roles after every upgrade. New permissions from a product update are granted automatically to the built-in Administrator role only. Custom roles do not receive them, so a new plan-changing capability arrives admin-only until you decide who else should hold it. That is the security-first default working as intended, and it only works if someone actually reviews. Put it on the quarterly admin health check.

Write the Rule Down, Not Just the Permission

Access control enforces a decision; it does not explain it. When a supervisor asks why they can no longer press Reschedule, "the software will not let me" is a worse answer than "we agreed one person owns the sequence, and here is who to call."

So record the split: who runs the scheduler, on what trigger, and who to ask when something needs to move. That belongs alongside your other written conventions, covered in documenting your plant's conventions. A plant that can name its schedule owner recovers from a bad day faster than one where five people all half-own the plan.

For the full administrator reference, read the EDGEBIC admin guide; for why hidden controls protect the plan rather than merely restrict people, how role-based access protects the schedule; and for what the plan is supposed to be doing in the first place, what production scheduling is.