Warehouse Organizer.com

F E AT U R E S U M M A R I E S · PA R T 2

◉

Users, Groups & Roles

Most business software gives you one dial: a role. Warehouse Organizer gives you three — group (which part of the business you can touch), role (how much you can do there), and scope (the whole organisation, or one site). They combine, so access fits the actual job instead of the nearest preset.

Why three dials instead of one: a warehouse lead, a bookkeeper, a seasonal picker at one site, an outside consultant and a customer placing orders are five genuinely different shapes of access. With one role list you either over-grant or invent a role per person. With group × role × scope, each of those five is a two-dropdown row on one page.

01	Group — what you see	Store, Fulfillment (Warehouse or Product), Accounting, HR, All, or a base role that spans every group.
02	Role — what you can do	A seven-rung ladder from Blocked to System Admin, evaluated per group.
03	Scope — where it applies	Organisation-wide by default, overridable per warehouse in either direction.
04	Invites	One invite flow, four very different shapes of account: employee, customer, consultant, and support.
05	API accounts	Any account can be turned into an API account, carrying exactly the permissions it was granted — no more.
06	Account security	Two-factor login, permission changes that land on live sessions, and a guard against locking yourself out.

Where it lives: Settings → Users — one page with an invite card, an organisation permissions table, and a per-warehouse permissions table. Everything in this summary is set from those three panels.

Warehouse Organizer — Users, Groups & Roles

Page 1

D I A L 0 1

Group — what you can see

A group is a functional area of the business. Assigning someone to a group decides which parts of the application exist for them at all: the menus, the pages, the dashboard tiles. Someone in the Accounting group does not see a stripped-down warehouse — they see an application that is about accounting.

Where: Users → Group column

THE GROUPS

GROUP	WHAT IT OPENS UP
Base (all groups)	The default membership row — one role applied across every area, for people whose job isn't compartmentalised
Store	Catalog, customer pricing, shop and cart, order management
Fulfillment — Warehouse	Warehouses, the map, bays, inventory, and the daily operations screens
Fulfillment — Product	The product master and product data, without the physical warehouse
Accounting	Costs, invoices, purchase orders
Human Resources	People records, HR documents, time and attendance
All / Admin	Every group at once — the administrator's row

WHAT THIS BUYS YOU

• Separation of duties without separate systems. Your bookkeeper genuinely cannot see pay rates; your HR manager genuinely cannot edit invoices. That's a control, not a hidden menu.

• The product master is its own group. Splitting Fulfillment — Product from Fulfillment — Warehouse lets a merchandiser or dataentry person maintain catalogue data without any access to stock, counts or the floor.

• A smaller app for everyone. Feature menus disappear entirely when the group doesn't cover them, so a picker's navigation has four items rather than forty.

Feature flags stack on top. If the business has Accounting switched off, nobody sees it regardless of group.

HOW IT WORKS

Access is not a single field on the user. It is a set of membership rows , each one carrying an organisation, an optional warehouse, a group and a role. A person can hold several rows at once — that is what lets one account be Admin for Accounting and View for Fulfillment.

Group rows override the base row, in either direction. A base role of Modify plus an HR group row of View means: Modify everywhere, View in HR. A base of View plus an Accounting row of Admin means the opposite. You can promote or demote a single area without disturbing the rest.

Warehouse Organizer — Users, Groups & Roles

Page 2

D I A L S 0 2 & 0 3

Role and Scope

The role says how far you can go; the scope says where. Roles are a strict ladder, so a permission check is a comparison rather than a checklist — and scope lets the answer differ from one site to the next.

Where: Users → Role column · Organisation vs Warehouse permission tables

THE ROLE LADDER

ROLE	WHAT IT MEANS
Blocked	Explicitly denied — used to shut off one area for someone who otherwise has broad access
View	Read the data, change nothing. The customer and read-only-auditor rung
Entry	Do the work: record counts, picks, punches and receipts, without editing the records behind them
Modify	Create and edit records — the working rung for supervisors and office staff
Delete	Modify, plus the ability to remove records
Admin	Administers users, permissions and organisation settings. New organisations start with one
System Admin	Cross-organisation support access. Staff only — see page 5

SCOPE: ORGANISATION AND WAREHOUSE

• Two tables, one model. The organisation table sets a person's default across the business. The warehouse table overrides it for a specific site.

• Overrides go both ways. An Admin for the whole organisation can be View at one site; someone with no organisation access at all can be Modify at exactly one warehouse.

• The seasonal-hire case. A temp gets one warehouse row at Entry in the Fulfillment — Warehouse group. They can pick, count and receive at that one site, and the rest of the business does not exist for them.

• The multi-site manager case. Warehouse rows at different levels for different sites, from a single account.

HOW IT WORKS

Resolution order. For any given check the app asks: is there a warehouse row for this site? Warehouse scope wins over organisation scope. Within whichever scope applies, the group row wins over the base row. Then the role is compared against the level the action requires — at least Modify , at least Admin , and so on.

The ladder is what makes that cheap. Because roles are ordered, every permission check in the application is one comparison against a threshold, not a lookup in a permission matrix that someone has to maintain.

Warehouse Organizer — Users, Groups & Roles

Page 3

F E AT U R E

Invites — four shapes of account

The invite itself is deliberately plain: first name, last name, email. An email goes out with a sign-up link, the invitee sets their own password, and no administrator ever handles a credential. The flexibility is in what you attach afterwards — the same three-dropdown row produces four very different kinds of user.

Where: Users → Invite User (admins only) · the sign-up link is also copyable from the page

THE FOUR SHAPES

SHAPE	TYPICAL SETUP	WHAT THEY EXPERIENCE
Employee	Group matching their department, role Entry or Modify, scoped to their site	An application about their job: a picker sees operations, a bookkeeper sees accounting
Customer	Store group, role View	Shop, cart, checkout, their own order history and printable invoices — and nothing operational
Consultant	One group, role View or Modify, often a single warehouse row	Exactly the area they were hired to work on, for as long as the row exists — revoked by deleting it
Support	System Admin, granted by the Warehouse Organizer team	Cross-organisation help-desk access for diagnosing a problem you've reported

WHAT MAKES IT WORK IN PRACTICE

• Customers and employees are the same system. A customer account is not a separate portal with its own login and its own user list — it's a membership row with the Store group at View. One user directory, one audit trail.

• Consultants get an expiry you control. Access ends when you delete the row, not when someone remembers to ask IT — and because the row is scoped, there is no window in which they could see payroll on their way to the warehouse data.

• One person, several organisations. Accounts aren't owned by an organisation, so an accountant serving three businesses uses one login and switches between them from the navbar.

• Pending invites are visible — listed with their sign-up link and a delete button, so an invitation that was never accepted is obvious rather than forgotten.

HOW IT WORKS

An invite creates the account in a pending state and mails a single-use sign-up link. The invitee chooses their own password, stored as a BCrypt hash — no administrator ever sees, sets or transmits one. Resets use the same expiring-link mechanism.

Support access is deliberately not self-service. The System Admin role is granted only out of band by the Warehouse Organizer team; it is not assignable through the Users page or the API, so no customer administrator — and no compromised customer administrator account — can mint cross-organisation access.

Warehouse Organizer — Users, Groups & Roles

Page 4

F E AT U R E

Any account can be an API account

There is no separate concept of an "integration user" with its own parallel permission model. API access is a checkbox on a membership row. Tick it and that membership can be used programmatically — carrying exactly the group, role and scope it already had, and nothing else.

Where: Users → Allow API column, per membership row

WHAT IT DOES

• Per membership, not per person. A user with three rows can have API enabled on one of them. Their integration reaches one warehouse at Entry while their own login still works normally everywhere else.

• Off by default. People who only use the browser never have an API surface, so the number of credentials that can move data is the number you deliberately created.

• Purpose-built service accounts. Invite integration@yourcompany like any other user, give it one group at the lowest role that works, tick Allow API, and you have a least-privilege service account created entirely from the Users page.

• Revocation is the same checkbox. Untick it and the credential stops working — no key rotation, no hunting through an integrations screen.

Documented REST API. The same endpoints the application's own screens use, with API docs linked from the navbar.

HOW IT WORKS

Tokens are minted per organisation. A client authenticates against the token endpoint for the specific organisation it intends to work in. Requesting a token for an organisation you hold no API-enabled membership in fails — the endpoint deliberately does not double as a way to discover which organisations an account belongs to.

The token carries a filtered permission set. When a request arrives bearing a token, the account's memberships are filtered down to only those with Allow API switched on before any permission check runs. A person who is Admin in the browser and API-enabled on one View row is View over the API. The UI permission and the API permission cannot drift apart, because they are the same rows with one filter applied.

Tokens are signed asymmetrically (RS256) and expire after one hour , so a leaked token has a short life and the signing key never has to be shared with a verifier.

Warehouse Organizer — Users, Groups & Roles

Page 5

F E AT U R E

Account security & lifecycle

The parts of user management that only matter when something goes wrong: proving who is logging in, making a permission change take effect immediately, and making sure nobody can lock the business out of its own account.

Where: Settings → Organization Settings → General · Users

WHAT IT DOES

• Two-factor authentication, per organisation. An administrator can require it for the whole organisation; every login then needs a one-time code delivered by email alongside the password. Codes expire after ten minutes.

• Passwords are never handled by an administrator. Users set their own on invite and reset them through an emailed, expiring link. Stored as BCrypt hashes.

• Permission changes land immediately. Change someone's role and their current session changes — no logout, no waiting for a token to expire, no window where a revoked permission still works.

• Last-admin protection. The system refuses the edit that would leave an organisation with no administrator. The most common way to lose access to a business system is simply not available.

• Removal is one action. Removing a user from an organisation revokes every membership row they held in it, across every warehouse and group.

• Everything is on the record. With write auditing enabled, permission changes are captured with the actor, the timestamp and what changed — queryable as a report.

HOW IT WORKS

Live permission propagation. When a membership row changes, the change is published on a message channel that every running application instance subscribes to. Each instance applies it to the affected user's stored session. That is why a revoked permission takes effect on the next click rather than the next login — and why it works the same way when the business is running on more than one server.

Sensitive values are scrubbed on the way to the log. Passwords, tokens, security keys, credentials and government identifiers are redacted by pattern before an audit record is written, so turning auditing up does not turn your log into a liability.

The short version
Group decides what exists for you, role decides how far you can go, and scope decides where.
Invites are plain by design — the account's shape comes from the row you give it, which is why
employees, customers, consultants and support all live in one user list. Any row can become an API
credential carrying exactly its own permissions, and any change to any of it takes effect on the next
click.

Warehouse Organizer — Users, Groups & Roles

Page 6