How to Assign Multiple Roles to a User in EDGEBIC

To assign multiple roles to a user in EDGEBIC by User Solutions, open the user's edit dialog on the Security tab and tick every role in the Roles checklist, then save. The person's effective rights become the union of every ticked role: a second role always adds capability and never removes any.

That single sentence about the union is the whole model, and it is the thing most often misunderstood when a permission behaves unexpectedly. For the ground-up setup, see how to set up users and roles.

Before You Start

• You are signed in as an administrator or with a role that includes the security permissions.
• The roles you want to assign already exist. If not, build them first: how to create a role.
• You know which permissions each role actually carries. Ticking a role by its name alone is how people accidentally hand out delete rights.

Assigning the Roles

1. Open the Settings tab, then the 🔒 Security tab, then the Users sub-tab.
2. Select the person's row and click Edit, or double-click the row.
3. In the dialog, find the Roles checklist.
4. Tick every role this person should hold. Untick any they should not.
5. Click the save button.

The dialog rewrites the role assignments to match exactly what is ticked. Roles you unticked are removed, roles you ticked are added, and roles you left alone stay as they were. There is no separate add and remove step.

Note that Username is read-only in edit mode. It is fixed at creation, by design, because it is the identity every audit entry hangs from.

What Changes When You Save

How to Check It Worked

Ask the person to sign out and sign back in, then look for the specific screen or button the new role was meant to grant. That is the real test, because permissions are loaded at sign-in.

If the button is still missing, the permission is not present in any role they hold. Go to Roles & Permissions, open each of their roles in turn, and check the relevant section of the permission tree. Permissions are grouped by area (Sales, Production, Master Data, Insights, Data, Settings, Security), then by module, then by action, so the one you want is usually two clicks from the section header.

Why the Union Model Matters

Because roles combine additively with no ranking, some designs that feel natural simply do not work:

• A restricting role does nothing. You cannot add a "no delete" role on top of a broad one to claw a permission back. Nothing subtracts.
• A one-role-per-person rule creates role sprawl. If every combination needs its own role, four job functions become fifteen roles, and every product update means editing all fifteen. Compose instead.
• Start narrow. Build roles from nothing and add permissions when somebody genuinely hits a wall. Widening a role is a two-minute job; discovering months later that everyone could delete work centers is not.

There is one more rule worth remembering at upgrade time: when a product update introduces new permissions, only the built-in Administrator role receives them automatically. Custom roles do not. That is deliberate and security-first, and it is why a new feature can be visible to an admin and invisible to everyone else until you go and grant it. Review your custom roles after each upgrade.

A Quick Worked Example

Acme runs three job functions. Planner carries the Production and Master Data permissions and no Security or Settings. Supervisor carries schedule viewing plus actuals logging. Reporting carries the Insights permissions and nothing else.

Jane plans and also runs the Monday morning numbers, so her user has Planner and Reporting ticked. Miguel supervises and covers planning when Jane is away, so his user has Supervisor and Planner ticked. Nobody built a Planner-Reporting role or a Supervisor-Planner role, so when a product update adds a new Insights permission, the administrator grants it once to Reporting and everyone who needs it has it.

Miguel later moves fully into planning. The administrator opens his user, unticks Supervisor, and saves. His actuals-logging right disappears at his next sign-in, without anyone touching a role definition.

Common Mistakes

Ticking a role by its name. "Reporting" sounds harmless until you open it and find a delete permission somebody added months ago. Read the permission tree before you assign.

Editing a role to fix one person. A role edit hits everyone holding it. If one person needs something different, either assign them a different role or create a narrower one.

Expecting the change to be instant. Rights load at sign-in. Have the person sign out and in before you start debugging.

Removing every role to restrict someone. A user with no roles can still sign in and simply sees almost nothing, which reads as a broken install. If the goal is to stop access, deactivate the account instead.

Forgetting custom roles after an upgrade. New permissions land on Administrator only. A quick review of each custom role after an update prevents the "why can only the admin see this?" ticket.

Next Steps

If the person you are editing has left rather than changed jobs, how to deactivate a user is the right action, and how to create a role covers building the permission bundles themselves. For the full task library, see the EDGEBIC how-to hub, and for the platform overview, EDGEBIC.