What Is a Security Role in Manufacturing Software? EDGEBIC Definition

A security role is a named bundle of permissions that gets assigned to users, and it is the only route by which anyone gains a right in the system. A permission is one atomic capability, such as viewing work centers, generating schedules or deleting customers. A role gathers a set of them under a label like Planner or Supervisor. A user holds one or more roles, and what that person can see and click is the union of everything their roles grant. EDGEBIC by User Solutions uses this role-based model throughout, with no per-user override layer beneath it.

This entry is part of the EDGEBIC glossary series introduced on the platform overview; the wider vocabulary index sits in the manufacturing glossary. Its companion entry is the effective permission, the resolved answer to "what can this person actually do?".

How a Security Role Works

The building keycard is the right analogy, and it is right in a specific way. Keycards are not cut per door. A site issues a small number of access profiles, "day staff", "night maintenance", "facilities", and each card is programmed with one or more of them. When the loading bay lock changes, you edit the profile rather than chasing every card in the building. A role works the same way, and for the same reason: rights that are defined once and reused stay reviewable, while rights granted individually stop being visible the day the person who granted them leaves.

Three properties define the model in practice.

Rights are additive. A user's capability set is the union of their roles. Assigning a second role can only ever add. There is no deny rule that overrides a grant, so the pattern of granting broadly and subtracting exceptions does not exist here. To take a capability away, you edit the role that grants it or remove the role from the user.

Enforcement is by hiding and refusing. Buttons and screens a user lacks permission for are hidden or refused rather than shown and failing, and that reaches all the way up. A user without the relevant rights does not see the whole Settings area, including the security screens themselves.

Rights load at sign-in. A newly assigned role takes effect at that user's next sign-in, because their permission set is resolved when the session starts. Editing the permissions inside a role applies to everyone holding it, and a session on the same machine can pick the change up immediately, while other sessions see it at next sign-in. That timing accounts for most "I gave them the role and nothing happened" reports.

One role is special. The built-in Administrator role always holds every permission, including new ones introduced by product updates, and it cannot be deleted. Neither can the founding administrator account created on first launch. Custom roles receive nothing automatically: when an update ships a new permission, only Administrator gets it, and every other role must be granted it explicitly. That is a security-first default, and it makes reviewing roles part of the upgrade rather than an afterthought.

A Concrete Example

A shop wants a Shop Floor Supervisor who can see the schedule, log actuals against jobs and correct operator entries, but who must not be able to delete master data or regenerate the whole plan.

The role is created with a name and a description, then permissions are ticked in a tree grouped by area, Sales, Production, Master Data, Insights, Data, Settings and Security, and then by module within each area. Each group carries its own select-all and clear buttons, so the workflow is usually to select all within one module and clear the two or three destructive rights rather than ticking twenty boxes individually.

The supervisor's role gets the schedule-viewing and actuals-logging permissions in Production, is left without delete permissions in Master Data, and is left with nothing in Settings or Security. It is then assigned to three users on the Users screen.

Now suppose one of those three also needs to enter sales orders. Because rights are additive and there is no per-user override, the answer is a second role holding the sales-order permissions, assigned to that one person. Their effective permissions become the union of the two roles. Nothing about the supervisor role changes for the other two users, and the reason that person can enter orders remains visible as a named role rather than as an invisible exception.

How EDGEBIC Uses Roles

Roles and users live together under the security area of Settings, on two sub-tabs. The users side handles account creation, role assignment, password resets, unlocking after a lockout, and activating or deactivating an account. The roles side handles the permission tree.

Two habits are worth adopting:

• Deactivate rather than delete. For a departure, unticking active bars sign-in while every historical link stays intact and the username cannot be reused by accident. Deletion is available and rarely the right answer.
• Review roles after every upgrade. Because only Administrator inherits new permissions, a capability shipped in a new release is invisible to your custom roles until someone grants it.

Every change made here, including role creation, permission edits, assignments and refusals, is written permanently to the security audit trail. That trail is append-only in the database and has no viewing screen in the application today; it exists as a record an administrator or support can query when a question arises. The concept has its own entry, the security audit log.

The step by step for defining a role and ticking its permission tree is in how to create a role.