Users, Roles & Permissions

Knowledge ERP is multi-user with role-based access control, so each person sees and does exactly what they should.

Users and seats #

Add team members as users. Each plan tier includes a seat cap — Starter (5), Growth (25), and Business (50) — and seats are priced per user. When the cap is reached the Create User button is disabled; upgrade your plan or remove an existing user to add more.

Service accounts do not occupy a seat. A service account is a user that exists only to own API tokens and cannot sign in. They are capped per tier separately — Starter (0, no API access), Growth (5), Business (15). See API: Getting Started. The Users list adds a Can sign in column to tell them apart from people, but only once your account actually has one — until then every row would say the same thing.

Inviting somebody, rather than inventing their password #

Adding a colleague sends them an invitation: an email with a signed link, good once and for seven days, on which they choose their own password. You never see it, and you never have to get one to them yourself.

If the invitation goes astray — spam folder, wrong address, they start a fortnight later — use Resend invitation on their row in the Users list. That issues a fresh link and stops the old one working. The option disappears once they have signed in; from then on, changing their password is theirs to do through Forgot your password? on the sign-in page.

The View User page says where the invitation got to: sent and not yet accepted, accepted on a date, or never needed because a password was set for them.

Setting a password yourself is still there, for somebody with no email address of their own — pick I will set a password now on the create form. It is now the deliberate choice rather than the only one, and the form says why you would rather not: you will have to get the password to them somehow, and you will both know it.

Everything about roles and permissions, in one place #

The staff form gathers the roles a person holds, anything granted on top of them, anything taken away, and any role that applies at one Location only, under a single Permissions & Roles heading. It is a heading and a border: the same fields, saved the same way, and refused to the same people as before.

What somebody may spend, and what they may sign off #

The Purchasing Limits card appears on accounts with the Purchasing module. Without it there are no purchase orders and no supplier bills, so the card is not shown and neither question is asked — on the form or on the View User page. Any figures already stored are left exactly as they are and come back if the module is added later.

Where it does appear, there are two figures, both of which have to be answered — they are not optional and they have no default, because blank means opposite things on the two of them and accepting a blank used to hand a new hire unlimited authority over other people's money.

• Purchase Limit — what this person may commit on their own. Nothing on their own holds every order they raise for approval; otherwise set the figure they may go up to.
• Approval Limit — what they may sign off for somebody else, on a purchase order or a supplier bill. Nothing means they can approve nobody's spending; Any amount, with no limit means exactly that, for as long as they hold the account.

Both appear on the View User page, spelled out, so you can check what you set without opening the form again.

Giving somebody slightly less than a role #

Two fields under the roles do the fine tuning, and both apply to that one person:

• Extra permissions, on top of their roles — give somebody one thing their role does not carry, rather than building a whole new role for it.
• Permissions to take away from this person — remove one thing their role does carry. Before this existed, giving a new hire "Warehouse but not the stock write-off" meant duplicating the role and working through a screen of a hundred checkboxes.

A permission taken away is refused everywhere — the app, the mobile app, and any API key that person owns — whatever their roles, their location-scoped roles or their extra permissions say. Taking away always wins. Both lists appear on the View User page.

The two fields are bounded differently, and deliberately so. Extra permissions only offers what you hold yourself — see You cannot pass on what you do not hold below. Taking one away is not bounded at all, because removing access is not the same kind of act as conferring it: somebody who has had manage_billing taken away can still take it away from a colleague.

Putting one back is a grant, and needs the permission. Clearing something from the take-away list hands the permission back, so it follows the same rule as granting it in the first place. Otherwise the fastest way around the rule would be to open your own record and lift the restriction that was placed on you.

The same rule applies to the Roles field. Assigning a role hands over everything it carries, so a role holding something you do not hold is greyed out. Roles this person already has stay tickable, so you can always take one off.

Who still has access, and who is using it #

The Users list answers both offboarding questions without leaving the screen.

Status is either Active or Disabled, and a disabled user's row is greyed back so it reads at a glance. Filter the list by Status to see just the people who have left, or just the ones who have not. Nothing is filtered away by default — an access audit needs to see everybody.

Last sign-in is when that person last signed in, to the app or the mobile app, and it sorts — which is how you find the dormant accounts. Somebody who has never signed in reads Never rather than being left blank: that is an invited seat nobody ever took up, which is a different problem from a seat that has gone quiet. A service account reads Not applicable, because it cannot sign in at all.

Individual API calls are not sign-ins and do not move this column. What a particular API key was last used for is recorded per key, in Settings → API Tokens.

Disabling someone who has left #

Use Disable on their row. It is not a cosmetic flag — a disabled user is refused everywhere:

• the app, immediately, including a session they already had open;
• the mobile app, both the password sign-in and the QR code;
• every API token they own.

Their password, roles, permissions and API tokens are all kept, so Enable puts them straight back to work — you do not have to reissue credentials or rebuild an integration. Their records, history and change-log attribution stay exactly as they are, which is why disabling is preferable to deleting somebody.

Disabling a user needs the same permission as editing one (update_users).

Two things are refused, with an explanation:

• You cannot disable yourself. It ends the session that would undo it.
• You cannot disable the last active user who can manage users. Even done deliberately, it leaves an account whose Users screen nobody can reach — and re-enabling requires that screen. Give somebody else that access first.

Disabling frees the seat #

A disabled user gives their seat back. Disable somebody who has left and you can hire into their seat straight away, without buying another.

The other half of that rule: re-enabling someone needs a free seat. If every seat is taken, Enable is refused and says so — disable somebody else, or add seats to your subscription. Without that, the cap would mean nothing: disable one person, hire their replacement into the freed seat, then re-enable the first, and two people would share one seat.

None of this changes your bill. Freeing a seat moves the cap — how many people may sign in — not the number of seats you pay for. To change what you are charged, change the seat count on your subscription.

Deleting frees a seat too, and restoring needs one back. A deleted user is not counted against your cap, so the same rule applies at the same strength: restoring somebody into a full account is refused, one at a time and in bulk alike. Free a seat or add one first.

Service accounts are unaffected either way: they occupy no seat, so one can be disabled, re-enabled, deleted or restored whatever your seat count is doing.

Permissions granted here also govern the REST API: an API token acts as a user, and can never do more than that user can. Revoking a permission narrows every token that person holds, immediately.

Roles and permissions #

Access is governed by roles. A role is a named bundle of permissions, and permissions are granular: for each thing in the product (customers, units, sales orders, …) there is a separate permission to see the list, to open one, to add one, to change one, to remove one, to put a removed one back, and to erase a removed one for good. Assign users one or more roles and they inherit those permissions. You can also grant extra permissions to one person on top of their roles, and take a permission away from one person whatever their roles say.

Permissions are named for what they let somebody do #

Each permission is named after its consequence rather than after the database verb behind it — Write off damaged, lost or expired stock, not Discard Units; See the list of Products and Open a Product, not View Any Products and View Products; Put back a Unit somebody removed, not Restore. Within each area they are grouped by the kind of authority they carry, in order:

Group	What is in it
Looking things up	Opening a list, opening one record.
Adding and changing records	Everyday work.
Day-to-day operations	Booking a delivery in, marking a transfer delivered, emailing a quote out.
Money: pricing and approvals	Setting prices, approving somebody else's spending, overriding a bill that does not match its order.
Removing records (can be undone)	Removing a record, and putting a removed one back.
Account administration	Billing, account settings, API keys.
Destructive: cannot be undone	Writing stock off, and erasing a removed record for good.

The consequential groups sit at the bottom, together and colour-coded, and the ones that need it carry a sentence saying what happens if you grant them. That is deliberate: the thing that lets somebody write stock off used to be called Discard Units, filed alphabetically among the ordinary permissions, and an owner who searched the list for "delete" believed she had caught everything dangerous and had not.

If you want the stored names — to match an API error message to a permission, for instance — switch on Show the technical permission names at the top of the role editor. It adds the raw name beside each label and changes nothing about what is granted.

When new resources are added to the product, their permissions are added to the catalog automatically — so roles stay complete as the app grows.

The default roles #

Roles belong to your account. Yours are yours alone: nobody outside your company can see them, and editing or deleting one changes nothing for anyone else.

Your account has Admin — every permission there is, including any added by a future release — plus the job-function roles below, which you can assign as they are or use as a starting point:

Role	May do	Deliberately may not
Warehouse	Full run of the floor: units, bins, transfers (including delivering one), stock counts and unit check-outs, and writing damaged or expired stock off (Discard Units). Add and edit products, categories and kits. Read locations, units of measure, vendors and purchase orders — enough for the Movement Log, Low Stock and the Reorder Queue to open.	Price lists and tax rates, raising or approving a purchase order, anything customer-facing, account settings or billing.
Buyer	Raise and amend purchase orders, add and maintain vendors and the products they supply, and receive stock against a PO. Read the products, bins, locations, units of measure, incoming bills and the approval queue.	Approve a purchase order or a bill variance, write or pay a vendor bill, touch account settings or billing.
Purchasing Manager	Everything Buyer can, plus approving purchase orders, vendor bills and bill variances, acting on approval requests, and the full vendor bill and vendor payment cycle (including cancelling a PO or a vendor).	Account settings, billing, users or the roles themselves — it is a purchasing authority, not an administrator.
Sales	The whole customer side: customers and contacts, opportunities, quotes, sales orders and customer returns, and customer segments. Read products, stock, locations, price lists and tax rates to quote from, and read customer invoices so the sales reports work.	Create or change an invoice, take a payment, issue a credit memo, set up a recurring invoice, move stock, or buy anything.
Front Desk	The diary and the people in it: book, move and cancel appointments, answer a customer's request to reschedule, and add a customer without leaving the booking form. Sets staff working hours — the record that decides whether anything can be booked at all. Reads appointment types and opening hours.	Change what the business offers or when it opens (appointment types, opening hours), anything with money in it, purchasing, users or billing.
Surveys	Write feedback surveys, send them out and chase them, and read every answer that comes back.	Write or change a response — the answers are somebody else's testimony, and the reporting built on them is only worth something if nobody in the ordinary run of the job can edit one. Nothing outside Surveys at all.
Bookkeeper	Both sides of the ledger: customer invoices, payments, credit memos and recurring invoices; vendor bills and vendor payments. Maintain tax rates. Read customers, contacts, sales orders, purchase orders, vendors, price lists and the products themselves. Manage account settings and billing.	Any inventory operation — no units, bins, transfers, counts or check-outs — and no purchase-order, vendor-bill or bill-variance approval. Entering a bill and approving it are deliberately different jobs.
Read-only	view and view_any on every business resource, so every list, record and report is legible.	Anything at all that writes, and none of the manage_* or approve_* authorities. It also cannot read users, user groups, the roles themselves or the Change Log.

A workspace that has just signed up and not yet chosen a plan is the one exception: it starts with Admin alone, holding the one permission Admin needs to open the plan page. The rest of Admin's permissions, and the job-function roles your plan includes, are created when your subscription starts. Workspaces that already have their roles keep them.

Each role carries a one-line description saying what it is for, and that description is shown beside the role on the staff form, where you are choosing one — not one menu section away. A role you write yourself can carry its own: fill in What this role is for on the role editor.

None of the eight can permanently delete a soft-deleted record (force_delete) — that stays with Admin, because it defeats the rollback every record carries.

Which default roles you get #

You are only given the roles your plan's modules make sense of. An account without the Purchasing module gets no Buyer and no Purchasing Manager, because there would be nothing for them to open. Read-only is always included, and so is Admin.

A role is included if you have any of the modules it works in, not all of them — Bookkeeper spans Sales and Purchasing, and you get it with either. Front Desk comes with the Appointments module, and Surveys with the Surveys module. Its permissions are not trimmed to match: a permission for a module you have not bought does nothing, since the module is enforced at the page itself.

Add a module later and the roles it unlocks appear on their own, with their original permissions, usually within a minute of the plan change.

What an update will and will not touch #

An update never writes over a role you have edited. Each is created once and then left alone, in both directions: a permission you removed stays removed, and one you added stays added. So a permission introduced by a later release is added to Admin only — re-check a role you rely on after a feature you care about ships.

A role you delete stays deleted. We record that you were given it, so nothing — a deploy, a plan change, adding the module a second time — brings it back. If you only want it out of the way for now, rename it or empty its permissions instead.

Building a role #

The role editor groups every permission into collapsible sections by area — Inventory, Sales, Purchasing and so on. There are several hundred of them, so three things make it navigable:

• Search. The box above the sections filters every permission at once. Type part of a screen name (invoice, bin) or an action (delete, approve) and only the matches stay on screen; sections with no match are hidden, and sections with one open themselves. Searching only changes what you can see — it never changes what is ticked, so you can filter, tick, clear the search and tick something else. A section's Select all applies to the matches you are looking at, not to the whole section.
• Expand all / Collapse all, next to the search box, for when you want to read the whole thing or get back to a short page.
• Start from an existing role, at the top of the create form. Pick a role and its permissions are ticked for you as a starting point; change whatever you like before saving. Nothing about the original role changes.

To copy a role outright, use Duplicate on its row in the Roles list. It creates a new role with the same permissions under a new name. Start from fills in the form and can only tick boxes the form offers, so it will not carry across a permission belonging to a module you no longer have — it says so when that happens. Duplicate copies everything else about the role, including permissions no section renders.

Neither one can carry across a permission you do not hold yourself; both say so when that happens, and how many.

You cannot pass on what you do not hold #

Nobody may grant a permission they do not themselves hold. The permission to manage roles is not the permission to invent authority: somebody given the job of looking after the staff list could otherwise tick "Change the plan, the seats and the payment details" onto a role, put that role on themselves, and cancel the subscription.

So on every screen that hands authority over — the role editor, Duplicate, Start from, the staff form's roles, extra permissions and location assignments — the things you do not hold are greyed out rather than hidden. Hiding them would make the screen lie about what exists; greying them says the permission is real, it is simply not yours to give. A short note above the list says how many, and what to do about it: ask somebody who holds it to grant it to you, or to make the change for you.

Two things this does not stop:

• Taking a permission away. You can untick a permission on a role, or take one away from a person, whether or not you hold it. Removing access is not escalation, and blocking it would leave nobody able to tidy up after somebody more privileged than themselves.
• Anyone who administers the account. The Admin role holds every permission there is, always — the app re-checks that on every deploy and whenever your plan changes — so an administrator is never greyed out and never notices this rule.

The practical shape of it: if you cannot grant something, somebody in your business can. If you have somehow ended up with an Admin role that is missing a permission, the next deploy or plan change restores it; if you need it back sooner, contact support, who can repair a locked-out account.

The Admin role also cannot be renamed, and its permissions cannot be changed. Several parts of the app recognise an administrator by that name rather than by a permission — the whole-account data export, the vendor bill tolerances, API keys. So the name has to stay occupied and the role has to keep meaning what those checks assume: freeing the name, or emptying the role, would both let somebody end up with "Admin" while holding nothing. Its checkboxes are shown for reference and are read-only, which is also more honest than before — an update always put back anything removed from Admin, so an edit there had never really stuck.

You can still take the role off a user, and you can create as many roles of your own as you like beside it. To give somebody less than full access, put them on a different role.

Permissions for modules you do not have #

The editor only offers sections for the modules on your plan. There is no point ticking Manufacturing permissions on a plan without Manufacturing — the module is refused at the screen regardless of what a role says.

There is one deliberate exception. If a role already grants something in a module you no longer have, that section still appears, marked with a note saying the module is not on your current plan. Those permissions do nothing while the module is off, but they are real and they are still on the role, so hiding them would mean an administrator could not see or clear something their own roles carried. Add the module back and they take effect again exactly as they were.

So the rule is: a module you do not have and a role that grants nothing in it — hidden; a module you do not have but the role grants something — shown, with the reason.

The note at the top of the editor tells you which modules those are, and it separates two different reasons in two sentences. A module that is on sale reads not on your plan and points you at Change plan, where you can add it. A module that has not been released yet — Manufacturing, Purchasing and Rentals — says so and stops: there is nothing to add and no price to quote, and sending you to Change plan for one would be sending you to a page that does not carry it. The same split runs through an appointment's next steps and the page you land on if you open a locked module directly. The sidebar's More modules entry only ever offers what is on sale — a module that has not been released yet is never counted toward it, so it never needs to make the split at all.

Editing a role never disturbs a permission the editor did not show you. That covers the sections above and anything filtered out by a search.

Every permission now has a checkbox. Approving purchase orders and bill variances, delivering transfers, managing API keys, account settings and billing used to have none — they were set by the default roles and could neither be granted nor taken away here, even though the View Role page named them. They are now in the section they belong to, like everything else, so a role you audit is a role you can fix.

A checkbox you may not tick is greyed rather than missing — see You cannot pass on what you do not hold.

What a permission actually stops #

Permissions are enforced, not advisory. A user without view_any for a resource cannot open it and cannot reach it by URL; without create the New button is gone and the create page itself refuses; without update the edit page will not open or save; without delete the delete action is not offered and does nothing if invoked. The same check runs on the related records shown inside a record — someone who cannot view sales orders will not see the Sales Orders tab on a customer.

Your menu is what you can do #

A page your role cannot open is not in your menu. If somebody has access to three things, the sidebar lists three things, and nothing about the rest of the product is theirs to reason about.

That means the menu is not a way to find out what exists. Two things are:

• Search. Type the name of a screen — "quotes", "staff availability", "audit" — and it is offered, labelled No access for your role, whether or not your role opens it. Searching is a deliberate act, so it costs nothing to answer it honestly, and it is the way to check whether a feature exists before asking for it.
• Opening it. A link from elsewhere in the product, a colleague's bookmark or a search result all lead to a page that names the role you hold, the permission it is missing, and where an administrator adds it — rather than a dead end.

If a module your account has not bought is still on sale, a single More modules entry sits at the bottom of the menu, for the people who could do something about it: anyone whose role carries manage_billing, which is the Admin and the Bookkeeper by default. It leads to Change plan, where every module on sale that is still missing from the plan can be added. It is a prompt to buy, so it is shown to whoever can buy; for everybody else it is hidden, for the same reason a role-locked page is. A module that has not been released yet is never counted toward it, since there is nothing to sell.

While an account is still choosing its first plan, More modules is not shown: nothing has been bought yet, so every module is missing at once, beside a page that is already offering them as checkboxes. Starting a checkout and abandoning it counts as still choosing. It appears once the account has taken out a subscription and something on sale is still missing from it, while a trial still counts as taken out. An account whose subscription has since lapsed does not see it — it is sent to Reactivate instead, where it can resubscribe or export its data and leave. Searching finds a locked module by name at any point, whether or not the reader could buy it — labelled Not on your plan, and pointing at the same refusal page as opening it directly.

The same applies to a few buttons: Record Payment on an invoice stays on screen and greyed for a role that may not write to it, with the permission named in its tooltip. That one is on a page you have already opened and are already working on, so the answer is worth having where you are. A greyed button is genuinely closed — the write is refused whether it is clicked or called directly — it is not merely hidden from view.

An action that is unavailable for a reason a permission would not change stays plainly out of the way: a paid invoice has no payment left to record, a converted quote is read-only for everybody, a bill on a three-way-match hold is not payable yet. Those are about sequence, not authority, and are already explained where it matters.

Two abilities are deliberately stricter. Bulk delete, restore and force delete act on a whole selection at once, so they require the permission account-wide; a role scoped to one location can still delete records one at a time at that location. And the Change Log now needs its own view_any_change_groups — it records the before and after value of every tracked field, so reading it is as revealing as reading the records themselves.

The working screens ask for update, not view. Ship, Receive, Approve, Match and the stock-count scanner each do a day's work on a record rather than display it, so reading the record is not authority to open them:

Screen	Needs
Sales order → Ship	update_sales_orders
Purchase order → Receive	update_purchase_orders
Transfer → Approve / Receive	update_inventory_transfers
Customer return → Receive	update_customer_returns
Stock count → Scan	update_cycle_counts
Vendor bill → Match	update_vendor_invoices

So a coordinator given read-only sales orders can follow an order's progress without being able to ship it. Approving a bill variance stays separate and stricter again — that is approve_bill_variance, on top of the above.

Approving a supplier bill is its own permission. Clearing a bill for payment is authorising money to leave the bank, so it is carved out of update_vendor_invoices as Approve Vendor Bills (approve_vendor_invoices). It used to come free with editing: anyone who could correct an invoice number could also approve the payment. It has a checkbox in the Purchasing section like any other permission.

Two things sit on top of it. The approver's Approval Limit — the same one that governs purchase orders — has to cover the bill's amount, and whoever raised the bill cannot approve it while anybody else in the account could. That second rule relaxes on its own where there is nobody else to ask, so a one-person business is never stuck; see Who may approve a bill.

Purchasing Manager starts with it and Admin holds it; Bookkeeper deliberately does not, so the role that enters bills is not by default the role that clears them. On an existing account nobody but the administrators has it on the day it ships — grant it deliberately.

Writing stock off is its own permission. Discard says a unit is gone — damaged, expired, scrapped — and takes its value off the valuation, so it is carved out of update_inventory_items as Discard Units (discard_inventory_items): a role can be trusted to fix a bin or a lot number without being trusted to decide a tool no longer exists. It has a checkbox in the Inventory section like any other permission, so a role built to keep hands off the stock simply leaves it unticked — the Discard action then does not appear on the unit or in the bulk menu, and the write refuses even if it is reached some other way. The Warehouse role starts with it; Admin holds it; no other default role does. Note this is not the same as delete_inventory_items, which removes the record (and is reversible — deleted records can be restored).

Pricing is its own permission. What a product sells for and what it costs are carved out of update_inventory_skus as Set Product Pricing (price_inventory_skus). One permission used to cover the whole product record, so anyone trusted to correct a name, a pack size or a barcode could also reprice every product — and the Warehouse role template grants product editing for exactly that record-keeping reason.

Without it, the Price and Cost fields are still shown — what a product sells for is ordinary information for anyone maintaining the products — but they cannot be changed, and the API refuses a price or cost on a create or update rather than quietly ignoring it. It has a checkbox in the Inventory section like any other permission.

No default role template starts with it. It is a new authority, so it begins unheld and is granted deliberately. An account owner is a super_admin and can always set pricing; anyone else needs the box ticked.

One role bypasses these checks entirely: super_admin, which our support staff use and which no account can create for itself — a role of that name in your own account is an ordinary role with only the permissions you tick.

Reports, dashboards and widgets #

A report is not a resource, so it has no permissions of its own. It is gated by the view_any permission for every kind of data it puts on screen — all of them, not any one of them. Cash Flow spans customer and vendor payments, so it needs view_any_customer_payments and view_any_vendor_payments; someone cleared only for what customers owe you would otherwise read what you owe your vendors. The same applies to a report's URL: without the permissions it is absent from the navigation and refuses if you visit it directly.

Dashboard widgets disappear instead of refusing — a user without the permission simply gets a dashboard without that widget, and it is not offered in the Customize list either. The Business Overview widget is the one exception worth knowing: it renders one block per area, so a user cleared for sales keeps the sales figures and never sees the AP balance beside them. The main dashboard itself is always reachable; it is the widgets on it that are gated.

Reports are module-gated as well. Holding every permission a report needs does not grant it if your plan does not include the module the report belongs to.

Here is what each report asks for:

Report / dashboard	Permissions required
AP Aging	view_any_vendor_invoices
Bills on Hold	view_any_vendor_invoices, view_any_purchase_orders
Invoice Aging	view_any_customer_invoices
Top Customers	view_any_customer_invoices
Cash Flow	view_any_customer_payments, view_any_vendor_payments
Sales Summary	view_any_sales_orders, view_any_customer_invoices
Sales Dashboard	view_any_sales_orders, view_any_customer_invoices
Sales Forecast	view_any_opportunities
Sales Pipeline (report and board)	view_any_opportunities
Quote Pipeline	view_any_quotes
Vendor Performance	view_any_purchase_orders, view_any_vendor_invoices
Purchasing Dashboard	view_any_purchase_orders, view_any_vendor_invoices
Valuation	view_any_inventory_skus
Expiring Stock	view_any_inventory_skus, view_any_inventory_items
Movement Log	view_any_inventory_skus, view_any_inventory_items
Low Stock	view_any_inventory_skus, view_any_purchase_orders
Reorder Queue	view_any_inventory_skus, view_any_purchase_orders
WIP	view_any_work_orders
Manufacturing Dashboard	view_any_work_orders
Production Schedule	view_any_work_orders
Material Availability	view_any_work_orders, view_any_inventory_skus
Feedback survey results	view_any_surveys, view_any_survey_responses, view_any_survey_invitations
Rental Calendar	view_any_rental_agreements
Appointments Dashboard	view_any_appointments

Low Stock and the Reorder Queue ask for purchase orders because both show what is already on order and offer to raise a PO from the row. If you want a stock-only view for warehouse staff, grant view_any_purchase_orders alongside inventory — the reports are built around the buying decision, not just the count.

Location-scoped roles #

Beyond global roles, you can grant a role scoped to specific locations. That lets someone be, say, a manager at one warehouse and read-only elsewhere — without giving them blanket access everywhere. Manage these from the Location Assignments section on a user's edit form, or from the role's detail view.

A location assignment is still an assignment, so the same rule applies: the Role list only offers the roles you could hand over account-wide. And a permission you hold only at a location does not let you grant it: a role is account-wide authority, and one warehouse's grant is not the account's to give.

A location-scoped role behaves as you would expect once you know where the location comes from.

• How narrowing works differs between screens and endpoints, and more than one summary of it here has turned out to be wrong. It is being documented properly rather than summarised; until then, treat the rules below as the parts we have checked, and test a role before relying on it.

• Seeing and opening a record depends on where the permission comes from. A permission somebody holds account-wide — granted to them directly, or carried by a role assigned across the whole account — reaches records at every location. A permission that reaches them only through a role assigned at a location reaches that location's records. A permission listed under Permissions to take away from this person is refused everywhere, whatever their roles say.

  Narrowing is not the same as confinement. Where somebody must not act at a location at all, the thing to get right is the permission: let it reach them through their role at that location rather than granting it to them account-wide.

• Creating a record at a location you have no permission for is refused, so a role at one location cannot be used to file work against another. A new record has no location of its own to be checked against yet, so the check is made against the location you chose — which means it holds whichever door the write came through: the app, the API and a connected AI assistant all ask the same question and give the same answer. The refusal names the location, says whether you hold no role there at all or a role that does not stretch to that job, and points you at the administrator who can change it.

• Every location picker says so up front. A location you cannot use is still listed — greyed out, and with the reason on the option itself: either you have no role at this location, or the permission your role there is missing, named the way the role editor names it. The locations you can use sort to the top, and a line under the field says an administrator can change that under Users & Access. Locations are never hidden from a picker: a warehouse you know exists that has quietly vanished from a list looks deleted, and that is a worse answer than "not yours".

• Bins and rental rates are narrowed too, since both are tied to a location: you are only offered the bins in warehouses you work in, so stock cannot be filed into another location's rack. The New Bin shortcut on a stock form is checked the same way — the bin lands at whichever location the form is pointed at, so pointing it at a warehouse your role does not cover is refused and says which location it was. A rental rate with no location is the account's default price card and stays available everywhere.

• Records that belong to no location — customers, price lists, tax rates — are not narrowed by location at all, since there is nothing to narrow them by. The same applies to a record whose location is simply left blank: it is treated as not belonging to a location rather than as belonging to one you are shut out of.

• Setup data is not narrowed to read. Appointment types and opening hours stay visible to anyone who may edit them, because they are usually maintained for the whole account rather than per location. Writing them is judged against the location: adding a day to a location's opening hours, changing one, or removing one asks whether your add or edit permission reaches that location, since those rules are what the public booking page offers your customers.

  This is the one place a delete is judged that way too. An Opening Hours delete permission held account-wide does not on its own let somebody close another location's trading week — not by clearing it in one save, deleting the rules one at a time, selecting them all for a bulk delete, or calling the API.

  It is the add and edit permissions that decide, though, so somebody holding those account-wide reaches every location and still edits and closes any location's week from the hours screen. To stop that, let their hours permissions reach them through their location role rather than granting them account-wide. Over the API the same change is also checked against where they are assigned, so that person is refused there while the hours screen still allows it. That is where things stand today rather than a distinction to rely on.

A role assignment with no location chosen is account-wide and grants its permissions everywhere. A permission granted through an ordinary (non-location) role is likewise account-wide — location assignments narrow the permissions they carry, and they do not take away a permission somebody already holds account-wide.

Scheduled work — nightly reports, digests, automation rules — covers the whole account regardless. It runs without a signed-in user, so there are no locations to narrow it to, and a monthly report that quietly covered one warehouse would be worse than one that covers them all.

Putting it together #

1. Create the roles you need (or use the defaults) and tune their permissions. Give each one a line saying what it is for.
2. Invite users and assign roles, answering both spend limits as you go. Take a permission away from anybody who needs slightly less than their role.
3. Where access should be limited by location, add location-scoped role assignments.