The Four EDGEBIC Roles Most Plants Need

Four roles cover almost every plant: a planner who runs the schedule, a shop supervisor who reports reality, a read-only role for everyone who watches, and a data entry role that runs imports. In EDGEBIC by User Solutions access is the union of a person's roles, so building these four before adding users means access grows deliberately instead of accumulating. This post is what each role should hold and, more usefully, what each should not.

The mechanics of creating one are in how to create a role. This post is the design that comes first.

How the Model Behaves

Three facts shape every role decision, and all three are easy to forget once you are deep in a permission tree.

Rights are additive. A permission is one atomic right, a role is a named bundle, and a user holds one or more roles. What a person can see and click is the union. There is no priority and no hierarchy, so a second role only ever adds capability. That makes exceptions easy to compose and mistakes hard to reverse, which is the argument for starting narrow.

Missing permissions hide controls. Buttons and screens a user lacks permission for are hidden or refused rather than shown and broken. So an absent control is information, not a fault. That includes the whole Settings area and the Security tab inside it.

Rights load at sign-in. A role change reaches a person at their next sign-in (immediately for someone signed in on the same machine). Half the "the permission did not work" reports are a sign-out away from resolving.

Role 1: Planner

The people accountable for the plan. In most plants this is one to four people.

Grant orders (view, add, edit), running the scheduler and rescheduling, drag-rescheduling on the Gantt, logging and editing actuals, routings including the graphical designer, master data (products, work centers, shifts, holidays), quotes and quote simulation, customers to view, reports and dashboards, and running imports and managing masks.

Leave out three things. The Security area, because planners should not be managing accounts. The data-clearing utility, which permanently removes rows with no undo. And the database connection, which requires a restart and can point the whole installation somewhere else. Those three are what make administrator access administrator access.

Consider also leaving out order deletion and closing if only supervisors should do those, which is a decision worth making explicitly rather than by default.

Role 2: Shop Supervisor

The people who report what happened, not what will happen.

Grant viewing the schedule, viewing orders, logging actuals, editing actual dates, reports and dashboards.

Leave out running the scheduler, drag-rescheduling, and routing edits. That is the split that matters most in a plant, because a supervisor rescheduling to make their own area look clear replans the whole plant to solve one area's problem. The reasoning behind it is in deciding who may change the schedule.

One note on the two actuals rights, which are separate on purpose. Logging is recording what happened. Editing actual dates is correcting what was recorded, and a correction moves the boundary between completed and remaining work that the next reschedule plans around. Most plants grant both to supervisors and neither to operators, since the shop-floor terminal has its own path for punches.

When one supervisor genuinely needs to sequence their own area, add a second role that carries the Gantt drag rather than widening the supervisor role for everyone. Composition is exactly what the union model is for; see how to assign multiple roles to a user.

Role 3: Read-Only

The cheapest role you will ever build and the one that prevents the most damage.

Grant viewing the schedule, orders, work centers, products, customers and quotes, plus reports, exports, and dashboards. Grant nothing that writes.

This role exists for management, sales, quality, and anyone who asks "where is job 4471?" It costs nothing, it cannot damage the plan, and it removes the only reason anybody ever borrows the planner's credentials. That matters because sign-ins, failed attempts, lockouts, user and role changes, and permission denials are all recorded permanently in an append-only security audit trail inside the database. There is no browsing screen for it in the application, so it is queried by your administrator or support when a question arrives, and every one of its entries is worthless if two people share a name.

Role 4: Data Entry

For a person who owns a recurring load and nothing else.

Grant running imports. Grant managing masks only if this person genuinely owns the mappings; if not, let an administrator own the masks and grant the run alone. Add view rights on products, work centers, and customers so they can confirm the load landed.

This role suits a plant where the ERP export arrives weekly and somebody other than the planner feeds it in. Where the planner does it themselves, skip the role entirely.

The Four at a Glance

Administrator is the fifth role and already exists. It is built in, always holds every permission including new ones added by updates, and cannot be deleted. Keep it on one or two people and do daily work under a named planner account instead, per protecting administrator access.

The One Maintenance Duty

New permissions from a product update land automatically on the built-in Administrator role only. Custom roles must be granted them explicitly, which is a security-first default and also a standing chore. The symptom when nobody does it is a feature that works for the administrator and for nobody else.

So after every upgrade, open each of your four roles and read the permission tree for anything new under its area. Put it on the quarterly admin health check so it happens even when the upgrade goes unremarked.

For the full administrator reference, read the EDGEBIC admin guide; for the model these templates sit on, users and roles explained; and for why hidden controls protect the plan rather than merely restrict people, how role-based access protects the schedule.