Roles and access

Who can do what, how offices work, and what Preview as is.

A person may have a home office and one or more roles. A person without a home office is unassigned until an administrator places them in one. Lists show the union of the home office and any grants. There is no “current office” to switch.

Permissions have a scope: all offices, this office, the team, or only what is assigned to the person. Where two roles grant the same permission, the widest scope wins. A written deny on a person beats every grant.

Nothing is anonymous. Access changes are written to an audit log.

The seeded roles

Role	What they can do	What they cannot do
Sales person	Their own cases: view and edit the inbox, confirm or exclude their enquiries’ lines, reply to the customer on their own enquiries, draft and issue quotations, see their sales orders	Confirm or exclude a line on someone else’s enquiry, approve a sales order, hand off to the ERP, manage people or mailboxes
Office head	The office: assign work, approve and send inbox items, confirm or exclude a line in line review, issue quotations, sales orders, decide a purchase order, ERP handoff, reports	Administer users and roles
Stakeholder	Read the catalogue, inbox, quotations, orders, ERP queue and reports across every office	Change anything
Administrator	Every office and every action, including users, roles and mailboxes	See the mail debug page (Developer only)
Developer	The same reach as Administrator, plus the mail debug page and its controls	— (kept separate so maintenance is visible in the audit log)

An office head’s approve and ERP keys are what stop a sales person signing off their own work.

Custom roles can be cloned from these. Lineage is recorded.

Only Developer sees the mail debug page. An Administrator can still grant it: by giving someone the Developer role, by adding Mail Debug to a role, or to one person as an exception. An Administrator using Preview as on a Developer can view the page, but cannot use its sync and model-call switches, because a preview is read-only.

Offices and grants

A business record belongs to one office. A user may be unassigned while being provisioned.
A person sees every office they hold — home plus grants.
Unassigned users are outside office-scoped lists; an all-office administrator can place them in an office.
A grant carries a written reason. It is auditable. It is not a mode.
Preview as lets an administrator look at the product as another person. It is a signed-in preview; it is not that person acting.

What this means in practice

The rail hides what you cannot do. An entry you lack permission for is not shown, rather than shown and then refused.
Confirming or excluding a line in line review needs inbox approval. The Sales person role holds it for the enquiries assigned to them, so the person assigned an enquiry confirms its lines; the Office head role holds it for the office’s, and follows each enquiry’s progress. A quotation is generated once every line it covers is confirmed or excluded (R38).
Mail waiting in Needs Review has the reach of other mail. An office head sees their office’s, and links it or gives it a type; a sales person sees, links and types the review mail assigned to them. Mail assigned to no office, and moving review mail to another office or owner, stay with people who read across all offices.
Replying to a customer from the inbox needs the send permission. The Sales person role holds it for their own enquiries, the Office head role for the office’s. A sales person replies from their own mailbox, or from a shared mailbox the conversation arrived in on an enquiry that is theirs. See Inbox.
A quotation carrying a deviation is still issued. Approval of the order is the office head’s; sending is gated on quote:send at the person’s scope. Sending from FlowOS is not live yet: a quotation is issued, downloaded and sent from the salesperson’s own mail.
Deciding a purchase order needs approve. Only an Office head or Administrator records Accept, Accept with deviations or Ask for amendment on a PO check (R116). A sales person re-matches the lines of a PO on their own enquiries. See Checking a purchase order.
Destructive actions are permissioned. Removing a mailbox, deleting a user, deleting a role — none of these are available to a sales person.
Password accounts cannot hold administration. Privileged roles stay on Entra identities.
The fluid library has its own permissions. Viewing, adding, editing and removing a fluid are the Substance Master row of a role, apart from the Item Master row. Every role and exception that held the Item Master’s view, add, edit or remove keeps the same access to the fluid library. Of the seeded roles, Administrator and Developer add fluids, including from a requirement line; the others read the library.

See First sign-in for the doors, and Automatic behaviour for what runs without a click.