What each role can do
These are the defaults in a new organisation. Four of the five are editable, so if yours has changed them, these are no longer accurate for you — see editing what a role can do.
| Role | Editable | Grants |
|---|---|---|
| Owner | No | Everything, including managing billing. Ignores any edits made to other roles |
| Admin | Yes | Full access to the app; manages members and settings; reads billing but cannot manage it |
| Member | Yes | Reads most things. No administration of teams, integrations or API keys |
| Warehouse | Yes | Full inventory control; reads catalogue, orders, customers and suppliers |
| Read only | Yes | Read across every surface, nothing else |
Owner
The backstop. Its permissions cannot be edited, and it ignores changes made to the others — which is what guarantees an organisation can always administer itself.
The only role that can manage billing. Every organisation needs at least one.
Admin
Everything an owner can do except manage billing, which is owner-only regardless of what you grant.
Where day-to-day administration belongs: inviting people, setting roles and scope, configuring integrations.
Member
Sensible for office staff who need to see and work with orders, stock and customers without administering the organisation.
Warehouse
The operational role. Full control of inventory — sites, locations, movements, allocations, transfers — plus the reads needed to pick and receive against orders, the catalogue, customers and suppliers.
Built for the floor rather than as a rung between member and admin.
Read only
View-only everywhere. Suitable for an accountant, an auditor, or anyone who needs to look with no risk of change.
These names mean nothing to the software
Yessort never checks a role by name — every decision resolves through the permission matrix. The table above describes the default bundles, not fixed behaviour.
A role says nothing about where
None of these restrict anyone to particular sites. That is site scope — and a member with no scope set can see every site.