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; the Users list marks them so you can tell them apart. They are capped per tier separately — Starter (0, no API access), Growth (5), Business (15). See API: Getting Started.

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: each resource (customers, inventory units, sales orders, …) has separate view_any, view, create, update, and delete permissions (plus restore / force_delete for soft-deleted records). Assign users one or more roles and they inherit those permissions. You can also grant additional permissions directly to a user, beyond their role(s).

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.

Every account starts with 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), cycle counts and unit check-outs. 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 catalogue, 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 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 role catalogue — 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.
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 product catalogue. Manage account settings and billing.	Any inventory operation — no units, bins, transfers, counts or check-outs — and no purchasing or bill-variance approval.
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 role catalogue or the Change Log.

None of the six 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. 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.

What a permission actually stops #

Permissions are enforced, not advisory. A user without view_any for a resource does not see it in the navigation 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.

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.

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 catalogue 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
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-scoped role behaves as you would expect once you know where the location comes from.

• Lists show only the locations you hold the permission at. A manager at the Denver warehouse sees Denver's sales orders and not Salt Lake's, and asking for Salt Lake explicitly — by filtering, or over the API — returns nothing rather than showing them.
• A single record is checked against that record's own location, so a manager at one warehouse cannot open or edit a unit held at another.
• Creating a record at a location you have no permission for is refused, so a role at one site cannot be used to file work against another.
• Bins and rental rates are narrowed too, since both are tied to a site: you are only offered the bins in warehouses you work in, so stock cannot be filed into another site's rack. 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 site rather than as belonging to one you are shut out of.
• Setup data is not narrowed. Appointment types and location hours stay visible to anyone who may edit them, because they are usually maintained for the whole account rather than per site.

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, they do not restrict permissions you already hold globally.

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.
2. Invite users and assign roles.
3. Where access should be limited by site, add location-scoped role assignments.