How Can We Help?
User Management is where administrators create the people who log in, decide which
company and branch each one belongs to, and grant the permissions that gate what they can see and
do. This chapter covers the screen and the data it writes; User rights &
groups explains the permission model, and Permission visibility
covers hiding permissions per partner type.
How to open it
From the main menu, click Administration and Setup (the gear / cog icon) to open its
submenu, then choose Users Management. User groups are on the sibling entry
Users Profile Management (see the next chapter).
Main menu → Administration and Setup → Users Management
If that entry is missing, your account lacks the Create/Edit User permission — ask an
administrator to grant it. These screens exist only on the modern client; the classic window/door
designer does not manage users, it only reads your permissions to decide what you can do.
From the main menu, click Administration and Setup (the gear / cog icon) to open its
submenu, then choose Users Management. User groups are on the sibling entry
Users Profile Management (see the next chapter).
Main menu → Administration and Setup → Users Management
If that entry is missing, your account lacks the Create/Edit User permission — ask an
administrator to grant it. These screens exist only on the modern client; the classic window/door
designer does not manage users, it only reads your permissions to decide what you can do.
What, where, who, when, why
| What | The create/edit screen for login users: identity and defaults (Detail), the permission tree, granted rights and group membership (User Rights), and per-user integration sub-records (Configuration). |
| Where | Main menu → Administration and Setup → Users Management (modern client only; requires the Create/Edit User permission). |
| Who | An administrator — in multi-partner setups, the partner type of the administrator’s own company filters the permission tree they can grant. |
| When | Onboarding and offboarding staff; when somebody changes branch, role, or needs one extra permission. Deactivating beats deleting — users are soft-deleted so history stays readable. |
| Why it matters | Every capability gate in the product reads these rows: the company decides the partner type (and thus visible permissions), the branch decides whose order it is, and the rights list decides what the user can confirm, price, or edit. Is Admin bypasses the list entirely. |
The screen at a glance
The form has three collapsible areas:
- Detail — the user’s identity and defaults (name, login, company/branch, language, UOM).
- User Rights — the permission tree, the granted-rights list, and the groups the user
belongs to (see the next chapter). - Configuration — integration sub-records (email account, QuickBooks, calendar).
What a user record holds
The most important fields on a user:
| Field | Meaning |
|---|---|
Company (partner) (col partnerid) |
The company the user belongs to. Also decides the partner type that drives permission visibility (see action exclusions). |
Branch / Alt branches (branch, alt_branches) |
The primary branch plus any additional branches. Alt branches are stored as a comma-separated list of branch ids. |
| Login / Email as login | The username, or the email address when “email as login” is on. |
| Password | Stored hashed, never in clear text. See the sentinel note below. |
| Language / Default UOM | UI language and the user’s default unit of measure for order entry. |
Is Admin (is_admin) |
Grants every permission, bypassing the rights list entirely (see the warning below). |
| Active / Deleted | Users are soft-deleted (deleted flag + who/when), not physically removed, so history stays intact. |
“Is Admin” overrides everything
A user flagged Is Admin receives all permissions regardless of what is (or is not) in their
rights list. Grant it sparingly. This is also why the Is-Admin checkbox is sometimes hidden — see
Permission visibility.
A user flagged Is Admin receives all permissions regardless of what is (or is not) in their
rights list. Grant it sparingly. This is also why the Is-Admin checkbox is sometimes hidden — see
Permission visibility.
Creating or editing a user
- Open Administration and Setup → Users Management from the main menu. The permission
tree loads, already filtered for your partner type. - Pick an existing user to edit, or start a new one.
- Fill in Detail: company, branch (and alt branches), name, login, language and default
UOM. - Grant permissions under User Rights — either add individual actions from the tree, or
tick a group to pull in its whole template (see next chapter). - Optionally set up the Configuration sub-records (email, QuickBooks, calendar).
- Save.
Worked example — onboarding an order-entry clerk
| Step | Value | Why |
|---|---|---|
| Detail → Company | Acme Windows (own company) | The company sets the partner type, which filters which permissions can even be granted. |
| Detail → Branch | East branch | Orders the clerk raises belong to the East branch; its number sequence and reports apply. |
| Detail → Login, Language, UOM | jsmith / English / Imperial | Identity plus the defaults the order screens start from. |
| User Rights → group | tick Order Entry group | One tick pulls in the whole curated template instead of hunting the tree action by action. |
| User Rights → one extra action | add View price | Groups are templates — individual actions still stack on top when a role needs one more. |
| Save | — | Nothing is written until Save; the clerk logs in immediately with the temp password flow. |
Password & secret fields show a placeholder
Editing an existing user shows a masked placeholder in the password (and API-key/secret) fields
rather than the real value. A new value is only sent when you actually change it — leaving the
placeholder untouched keeps the current password.
Editing an existing user shows a masked placeholder in the password (and API-key/secret) fields
rather than the real value. A new value is only sent when you actually change it — leaving the
placeholder untouched keeps the current password.
Saving rewrites the whole rights list
When you save a user, their existing rights are cleared and re-inserted from what is on the
screen — the screen is the source of truth, not a delta. Make sure the rights list is complete
before saving; anything not shown will be removed. (The rights themselves are stored in the
partner database, while the user record lives in the central database — a save touches both.)
When you save a user, their existing rights are cleared and re-inserted from what is on the
screen — the screen is the source of truth, not a delta. Make sure the rights list is complete
before saving; anything not shown will be removed. (The rights themselves are stored in the
partner database, while the user record lives in the central database — a save touches both.)