How to Set Up Users and Roles in EDGEBIC, Step by Step

Setting up user permissions in manufacturing software is usually a twenty-minute job that gets postponed for a year, and the cost of postponing it is a shared login that makes every "who changed this?" question unanswerable. In EDGEBIC by User Solutions the whole task is four steps: create the founding administrator, build two or three roles from the permission tree, create named users and tick their roles, and force a password change at first sign-in. This post walks each step with the real dialogs and fields.

If you have not read the model yet, EDGEBIC users and roles explained covers what permissions, roles, and users mean and how they combine. This post assumes that vocabulary and gets to the clicks.

Step 1: Create the Founding Administrator

The very first time EDGEBIC starts against a new database, the Create administrator account dialog appears before anything else, including the main window.

The default policy is at least 8 characters with an uppercase letter, a lowercase letter, and a digit. Special characters are not required by default, and your installation may be configured more strictly.

Click Create administrator. The Sign in to EDGEBIC dialog opens, you sign in with what you just typed, and the signed-in name appears in the main toolbar's identity strip. Sign out returns to the sign-in dialog.

Treat this account as a system record rather than a daily login. It cannot be deleted, it holds every permission, and it is the thing you fall back on when a role change goes wrong.

Step 2: Build the Roles Before the Users

Build roles first. Creating users first means going back to edit every one of them.

1. Open Settings, then the Security tab. Two sub-tabs appear: Users and Roles & Permissions.
2. On Roles & Permissions, click New role.
3. Enter a Role name (for example Shop Floor Supervisor) and a Description.
4. In the Permissions tree, tick the capabilities the role should have. Permissions are grouped by area, then by module. Each group has its own Select all and Clear buttons, and a Select all / Clear all pair at the top covers everything.
5. Save.

The tree's seven areas are Sales, Production, Master Data, Insights, Data, Settings, and Security. Two habits make this step fast and safe:

• Start from nothing and add. Use the module-level Select all inside Production or Master Data to grab a block, then untick the delete rights you do not want. Granting the least that does the job is easier to correct later than clawing rights back.
• Leave Settings and Security clear on every role except Administrator. A user without Settings permission does not see the Settings tab at all, which removes the database connection and the Clear Data Tables utility from their reach in one tick.

A pair of roles covers most plants: Planner (Production and Master Data, no Security, no Settings) and Supervisor (schedule viewing plus actuals logging). Add a quoting role if sales runs their own promise dates.

Step 3: Create the Named Users

1. Back on the Users sub-tab, click New user.
2. Fill in the dialog.

3. Save. The new user appears in the grid with columns for username, full name, email, roles, active, locked, and last login.

Tick Must change password on next login for every account you create. It means the temporary password you type (and possibly say out loud) stops being valid the moment the person signs in.

Note that the username cannot be changed after creation. Pick a convention before you start: first initial plus surname is the one most shops settle on.

Step 4: The Toolbar Actions You Will Actually Use

The Users toolbar carries the whole lifecycle:

Prefer Activate / Deactivate over Delete for departures. The account's history stays intact and the username cannot be reused by accident.

What Happens When You Save

Timing matters when you are changing access on a working shift.

The practical consequence: tightening a role at 10:00 does not eject someone who is mid-edit on their own machine. Plan role changes for a shift boundary if the change removes rights people are currently using.

Step 5: Verify by Signing In as Each Role

The step almost everyone skips, and the one that catches every mistake in the previous four.

Before you hand accounts to people, sign in as one account per role and try to do that role's actual job. For a Planner account: open the routings, change something small, run the scheduler, read the result. For a Supervisor account: open the schedule and log an hour against an operation.

Two failure shapes show up immediately:

• A button is missing that the person needs. The role lacks that right. Edit the role, or assign a second one; rights add up.
• A screen is visible that should not be. Usually Settings, and usually because a section-level Select all was clicked without unticking afterwards. Clear the Settings and Security sections on every non-administrator role.

Ten minutes here saves the first week of "I cannot do X" messages, and it is the only way to see the application the way your team will see it. Remember that a user without a given permission does not see a greyed-out button: the screen is simply smaller.

Rolling Roles Out Without Blocking a Shift

Timing matters when a change removes rights people are currently using.

Role permission edits reach everyone holding the role, and a person signed in on the same machine picks changes up immediately. That means tightening a role at 10:00 can visibly remove a button from someone mid-task. Nothing is lost and nothing breaks, but it is a surprise, and surprises cost trust.

Three habits handle it:

1. Add rights any time. Adding never disrupts anyone.
2. Remove rights at a shift boundary, and say so first.
3. Create new accounts ahead of the person's start date, with the must-change tick set. A new user's rights load at their first sign-in, so nothing needs to be timed.

A Worked Sequence: One Plant, Four People

The documented example is Acme Industries growing from one planner to a team of four.

1. The founder creates the admin account on first launch and works alone on the default local database.
2. IT provisions a shared SQL Server, and the administrator switches the connection (covered in how to install and connect EDGEBIC).
3. The administrator creates a Planner role (Production and Master Data permissions, no Security, no Settings) and a Supervisor role (schedule viewing plus actuals logging).
4. Users jsmith and mlopez are created with Must change password on next login ticked, holding Planner and Supervisor respectively. Each signs in from their own PC pointed at the same database, and each sets their own password.
5. On Monday, mlopez mistypes her password five times and the account locks. The administrator opens Users, selects her, clicks Unlock, and she is back in immediately.

That is the whole lifecycle, and step 5 is the one you will repeat. For the routine an administrator runs each time a new planner joins, role first and account second, see onboarding a new planner account.

After the First Setup

Two maintenance habits keep this from decaying:

Review custom roles after every upgrade. New permissions introduced by an update are granted automatically to the Administrator role only, so a new feature appears for you and stays invisible for everyone else until you grant it.

Keep one break-glass administrator besides the founding account, with a strong password stored in your password manager. It is the account you use when the person who normally administers the system is on holiday.

For what happens behind the sign-in dialog (password storage, lockout, and the audit trail), read how EDGEBIC protects your schedule data. For the failure modes that generate most support calls, read user and permission mistakes in EDGEBIC. The wider administrator's journey is in the EDGEBIC admin guide, and the product overview is at EDGEBIC.