What Is a Bootstrap Administrator Account?

A bootstrap administrator account is the first user account on a new database, created by a dedicated dialog that appears before anything else the very first time the application runs against it. It exists to break a circular dependency, and once it exists, every further account and role is managed through the ordinary security screens.

This entry defines the bootstrap administrator and shows how it reads inside EDGEBIC by User Solutions. For the wider index of terms, see the manufacturing glossary; for the model it unlocks, see EDGEBIC users and roles explained; and for the bundle of rights it holds, see what is a security role.

How It Works

Role-based access has a chicken-and-egg problem on an empty database. Permissions are granted through roles. Roles are created and assigned by someone with the right to administer security. On a fresh database nobody exists at all, so nobody can grant anything, and the system would be permanently unreachable.

The bootstrap administrator is the answer. The very first time the application starts against a new database, a create-administrator dialog appears ahead of everything else, asking for a full name, an optional email, a username, and a password with its confirmation. The password must meet the standard policy, and the requirement is shown as a hint under the field. Completing the dialog creates the account, and the sign-in dialog follows immediately.

From that moment the special case is over. The new administrator signs in and works through the normal users and roles screens like anyone else. There is no separate administrative back door, no second mechanism, and nothing about the founding account that behaves differently day to day.

Two protections stay in place permanently. The founding administrator account cannot be deleted, and neither can the built-in Administrator role. Both exist so that a system cannot lose the ability to administer itself through an ordinary cleanup. Everything else about the account is editable: it can be renamed, given a new password, and joined by as many other administrators as you like.

The built-in Administrator role also always holds every permission, including any introduced by later updates.

A Concrete Example

A shop installs the application on a workstation and starts it. Before the main window appears, the create-administrator dialog opens. They enter a full name, choose the username admin, set a password meeting the policy, and confirm. The sign-in dialog opens and they sign in with what they just created. The identity strip on the toolbar shows who is signed in.

Their first real task is not scheduling but security. They open the security settings, create a role called Planner, and tick the permissions that role should carry from the grouped permission tree. Then they create a user for their planner, tick the Planner role, set a temporary password, and tick the option that forces a password change at first sign-in.

A year later that founding administrator leaves the company. The handover does not involve deleting anything. A new user is created for the incoming administrator, given the built-in Administrator role, and verified as able to sign in and reach the security screens. Only then is the departing account's password reset and the account deactivated, which bars sign-in while leaving every historical record intact and preventing the username from being reused by mistake.

At no point is the shop left without a working administrator, which is the entire discipline.

How EDGEBIC Uses It

In EDGEBIC, the create-administrator dialog is the first thing shown on first launch against a new database, and the account it produces is the founding administrator. That account and the built-in Administrator role are both permanent: neither can be deleted.

The Administrator role always holds every permission, including permissions added by product updates, so an administrator never loses access to a newly shipped module. Custom roles are treated differently on purpose. A new permission is not granted to them automatically and must be ticked explicitly, which is a security-first default and the reason to review custom roles after an upgrade.

Permissions come through roles only. There is no per-user grant or deny screen, so widening what one person can do means either assigning them another role or editing a role they already hold. Because rights are the union of a user's roles, adding a second role can only ever add capability.

Everything the founding administrator does is recorded. Account creation, role creation, role assignment, permission grants and revokes, sign-ins, and lockouts all land in an append-only security trail inside the database. There is no viewing screen for that trail in the application; it is queried by an administrator or support when a genuine compliance or investigation question calls for it.

For the standard the founding password has to meet, see what is a password policy. For how rights resolve at sign-in, see what is an effective permission, and for the record of every administrative act, see what is a security audit log.