Onboarding a New Planner Account in EDGEBIC

Onboard a new planner by assigning an existing role rather than inventing one, forcing a password change at first sign-in, and widening access only when the person hits a real wall. In EDGEBIC by User Solutions a user account is small to create and hard to un-grant, so the safe sequence is role first, account second, additions later. This post is the onboarding routine an administrator runs when a new planner joins.

Offboarding has its own post: deactivating users and offboarding. This is the other half. It assumes your roles already exist; if they do not, build them first from the four roles most plants need.

Start With the Role, Not the Person

The temptation on a Monday morning is to create the account and sort out access later. Later never comes, and the interim grant is usually Administrator.

Access is role-based: a permission is one atomic right, a role is a named bundle of permissions, and a user holds one or more roles. What a person can see and click is the union of their roles. That union is the reason to start narrow. A second role only ever adds capability, so widening access later is a two-minute edit. Narrowing it means deciding which of two roles to remove from someone who has been using both.

So before the account exists, confirm there is a role that describes the job. A planner role typically covers orders, running the scheduler, working the Gantt, logging and editing actuals, routings, master data, quotes, and reports. It typically does not cover the Security area, the data-clearing utility, or the database connection. The mechanics of building one are in how to create a role.

Create the Account

On the Security tab in Settings, the Users list has a New user button. The dialog is short.

Two of those rows carry more weight than they look.

One account per person, never a shared login. The security audit trail records sign-ins, failed attempts, lockouts, user and role changes, and permission denials permanently. All of that is worth exactly nothing if two planners share a name. There is no browsing screen for that trail inside the application: it is an append-only record your administrator or support can query, which makes attribution at the account level the only thing keeping it meaningful.

Must change password on next login. The person signs in once with the temporary password you set and is then required to choose their own. It costs you nothing and means the password you typed into a chat window stops working the first time they use it.

The username cannot be changed after creation, so agree the naming convention before you start rather than after the third account. That convention belongs in your written conventions document, covered in documenting your plant's conventions.

What Takes Effect When

New planners are often told their access is set up and then find it is not, which is almost always a timing question rather than a permission one.

The practical rule: if a button is missing after you granted the permission, sign out and back in before investigating anything else. Screens and buttons a user lacks permission for are hidden or refused rather than shown and broken, so an absent control is information, not a fault. When it survives a re-sign-in, walk the role's permission tree for the specific action. The general triage lives in a user cannot sign in and user and permission mistakes.

What a New Planner Can Safely Break

This question decides how nervous you need to be, and the answer is reassuring.

Grid and panel layouts save per user automatically. The scheduler display configuration (colors, bar labels, overlays, timeline range, what a drag is allowed to do) is also per user and per machine, and none of it changes the engine's math. Two planners can configure their screens completely differently and still see the same underlying plan. So a new planner rearranging columns on day two affects nobody, and any view's configuration dialog has a Reset to Defaults button when they overdo it.

What does affect everyone sits in three places: the site scheduling policy on the Settings Schedule tab, the database connection on the DataSource tab, and the data-clearing utility under Data Management. Keep all three out of a starter role. The reasoning behind that split is in how role-based access protects the schedule.

The First Week

Access is the easy part. What makes a planner productive is the loop, and it is worth walking with them once on real data: import or enter the orders, run the scheduler, look at the plan on the Gantt, log an actual, then reschedule and watch what moves.

The single most useful thing to tell them in that first week is what does not move. Completed work is never repositioned by a reschedule. Operations with an actual start and an actual end stay exactly where they happened, and the engine replans forward from where the job actually stands. A planner who trusts that stops being afraid of the Reschedule button, and a planner who is afraid of it stops rescheduling, which is how a plan goes stale.

The Onboarding Sequence

Onboard this way and access grows deliberately instead of accumulating. For the full administrator reference, read the EDGEBIC admin guide; for the model underneath role design, users and roles explained; and for what your new planner is actually being hired to do, what production scheduling is.