EDGEBIC Users and Roles Explained: Who Can Change the Schedule

Manufacturing software user roles answer one question that gets expensive when nobody has answered it: who is allowed to change the production schedule? In EDGEBIC by User Solutions, access is role-based. A permission is one atomic right, a role is a named bundle of those rights, and a user holds one or more roles. Everything a signed-in person can see and click is the union of their roles. That model is small enough to explain in a meeting and precise enough to survive an audit.

This post covers the model itself: what the pieces are, what the permission tree actually covers, and which roles most shops end up building. The step-by-step setup lives in how to set up users and roles in EDGEBIC, and the protection mechanisms behind sign-in live in how EDGEBIC protects your schedule data.

Three Words Cover the Whole Model

The arithmetic is deliberately simple. A user's rights are the union of every role they hold. There is no role priority, no ranking, no inheritance chain. Assigning a second role only ever adds capability, never removes any. That property matters more than it sounds: it means you can answer "why can Jane do this?" by reading her role list, without tracing an override chain.

Permissions are granted through roles only. There is no per-user grant or deny screen. If one person needs a slightly different set of rights, you create a narrower role (a "Planner, no delete" variant, say) and assign that. The trade is deliberate: a little more role maintenance in exchange for access that stays explainable.

What the Permission Tree Actually Covers

The role editor presents permissions as a tree, grouped by area and then by module. Each group carries its own Select all and Clear buttons, with a Select all and Clear all pair at the top for the whole tree.

The granularity that matters in practice sits inside Production and Data. Running the scheduler, dragging a bar on the Gantt to reschedule it, editing actual start and end dates, and logging shop floor punches are separate rights, because they belong to different people. A supervisor who logs actuals has no business regenerating the plan. A planner who regenerates the plan rarely needs to hand-edit an actual date after the fact.

Data is the other place to be careful. Running an import and managing import masks are separate rights: the person who defines a column mapping once is not necessarily the person who clicks Run every Monday morning. If import masks are new to you, EDGEBIC import masks explained covers how they work.

The Two Records You Cannot Delete

Two things are protected by design.

The built-in Administrator role always holds every permission, including new ones added by product updates, and it cannot be deleted. The founding administrator account, created on the very first launch against a new database, cannot be deleted either. Together they guarantee that no combination of clicks locks a shop out of its own scheduling system.

That protection has a corollary worth stating: the founding admin account is a system record, not a working login. Create named accounts for the actual people and use them. Shared logins turn every audit question into a shrug.

Four Roles Most Shops End Up Building

You do not need many roles. Most plants land on three or four.

The documented worked example follows this shape. A four-person plant creates a Planner role (Production and Master Data permissions, no Security, no Settings) and a Supervisor role (schedule viewing plus actuals logging), then assigns them to two named users with "Must change password on next login" ticked so each person sets their own password on first sign-in.

One person can hold two roles. A working supervisor who also plans a cell gets both Planner and Supervisor ticked, and their rights add up.

What Changes After a Software Update

This is the behavior that surprises administrators most, so it is worth understanding before it bites.

When a product update introduces new permissions, only the built-in Administrator role receives them automatically. Custom roles do not. A new feature therefore appears to work for the administrator and to be missing for everyone else until someone grants the new right explicitly.

That is a security-first default, not an oversight. A capability that did not exist last month should not silently land in the hands of everyone who happens to hold a role called Planner. The habit it demands is small: after every upgrade, open the roles and review what is new. Ten minutes, once per release.

Roles Are a Data-Quality Tool, Not Only a Security One

Access control in a scheduling system does more than keep people out. It keeps the plan honest.

The two most destructive rights in the application are the ones that change the database connection and the ones that clear data tables. Neither belongs on a Planner role. A planner who accidentally opens the Clear Data Tables dialog from a toolbar button and works through it has removed rows with no recycle bin behind them. Withholding that right is not distrust: it is the same reason a CNC program has a dry-run mode.

The same logic applies to the audit trail. Every security-relevant event (sign-ins, failed attempts, lockouts, user and role changes, permission denials) is recorded permanently, and that record is only worth something if actions map to individual people. One account per person is what makes an audit trail evidence instead of noise. Manufacturers working under quality systems that require traceable operator records will recognize the pattern from audit-ready scheduling; the standards bodies that publish those expectations, including ASCM, have been saying the same thing about shared credentials for years.

What a Role Does Not Do

Two boundaries are worth drawing, because expecting a role to enforce them wastes time.

A role does not change what the engine computes. Permissions decide who may trigger a scheduling run, not how that run behaves. The engine's rulebook is the site-wide scheduling policy, and its inputs are your master data. A planner and an administrator who both run the scheduler get the same plan. See how to configure scheduling policy in EDGEBIC for the settings that do change the result.

A role does not stop a manual drag from overbooking a machine. The Gantt uses an override-and-warn model: feasibility of a hand-placed operation is the planner's judgement, and the next run resolves it. If you want drags prevented for a group of people, the honest lever is the drag-reschedule permission on their role rather than any display option.

What a role does do, precisely, is decide which operations a person may perform and which screens they may open. That is a narrower promise than "access control" usually implies, and it is worth stating plainly so nobody builds a policy on top of a capability that is not there.

Roles and the Shop Floor Kiosk

The shop floor kiosk is where most plants first feel the value of separating rights. Operators log punches and hours against scheduled operations from a simplified terminal, which writes actuals into the same database the planner reads.

That flow needs exactly one right on the operator side: logging actuals. It does not need schedule generation, routing editing, or anything under Master Data. A role built for the kiosk is one of the shortest role definitions you will write, and it is the one that most reduces the chance of an accidental change reaching the plan. The kiosk itself is covered in the EDGEBIC shop floor guide.

A Twenty-Minute Role Design Worksheet

Answer these five questions with the plant manager, and the role list writes itself:

Five answers usually collapse into three roles. If they collapse into six, one of the questions is being answered per person rather than per job, and that is the point to simplify rather than to build six roles.

Where Roles Sit Relative to the Rest of the Setup

Roles are one of the last things you configure and one of the first things you should think about. The sequence that works:

1. Install and connect the database (how to install and connect EDGEBIC).
2. Create the founding administrator on first launch.
3. Build master data: shifts, products, work centers, routings.
4. Decide who does what, then build roles to match.
5. Create named users, tick their roles, and force a password change on first sign-in.

Steps 1 through 3 are covered in the greenfield setup walkthrough. Step 4 is a conversation with the plant manager, not a software task. Step 5 takes about a minute per person.

Two practical rules from the documentation are worth carrying into that conversation. Grant the least that does the job, then add permissions when someone genuinely hits a wall, because adding rights is easier than clawing them back. And keep exactly one break-glass administrator besides the founding account, with a strong password stored in your password manager.

Where to Go Next

Roles are the smallest part of an EDGEBIC deployment and the part that pays back fastest, because it decides what a mistake can cost. Read how to set up users and roles in EDGEBIC for the click-by-click version, how EDGEBIC protects your schedule data for password handling, lockout, and the audit trail, and user and permission mistakes in EDGEBIC for the failure modes that account for most support calls. The full administrator's journey, from installer to multi-user, sits in the EDGEBIC admin guide.

Bring your current access list (even if it is one shared login) to a demo of EDGEBIC, and we will map it to roles on the call.