Permissions reference
Every action on a sales order — creating, editing, approving, fulfilling, refunding — is gated by a granular permission. This page lists each permission, maps every action to the permission that unlocks it, and covers the non-permission gates (the live edit lock and channel restrictions) that can block an action even when your role allows it.
How sales-order permissions work
Most permissions are enforced in two independent layers:
- The interface hides or disables any control you can't use. A user without Fulfill never sees the Fulfill button.
- The API re-checks the permission on every request and returns a
403if you lack it, so the action can't be triggered around a hidden button.
Two permissions — Refund and Manage shipping — are the exception: they gate their controls in the interface only. The underlying API request is still protected, but by a broader grant (the Update permission or the orders:write token scope) rather than by that specific permission. See Permissions enforced in the interface only before you rely on either one to restrict access.
Two switches sit above the individual permissions:
| Switch | Effect |
|---|---|
| Granular permissions (per-tenant feature flag) | When off (the default), no sales-order action is permission-gated — every signed-in user can do everything. When on, users act through roles that hold specific permissions. |
| Admin users | Admins bypass every sales-order permission check, in both the interface and the API, whether or not they've been assigned the permission explicitly. |
The first time a tenant enables granular permissions, every existing non-admin user is granted a Full Access role that holds every permission — so no one loses access the moment the flag flips. Teams then build scoped roles (for example a Warehouse Picker role that holds only Fulfill and Print) and remove Full Access when they're ready to lock things down. An administrator manages roles and their permissions in Settings.
The sales-order permissions
These are the permissions in the sales_orders group. Each row is one permission and the actions it unlocks.
| Permission | Grants the ability to |
|---|---|
View (sales_orders.index / sales_orders.show) | Open the sales orders list and any order's detail page. |
Create (sales_orders.create) | Create a new sales order. |
Update (sales_orders.update) | Edit an order — header, addresses, lines, discounts, charges, notes, tags, custom fields — plus allocate stock, revert to draft, archive, duplicate, resend/exchange, and regenerate accounting. |
Delete (sales_orders.delete) | Delete orders (single, bulk, or as a tracked job). |
Approve (sales_orders.approve) | Approve or reserve an order. |
Cancel (sales_orders.cancel) | Close or cancel an order. |
Fulfill (sales_orders.fulfill) | Fulfill, bulk-fulfill, mark for pickup, dropship, dispatch to a provider, and reshape fulfillments (split, move, merge, void, restore). |
Manage payments (sales_orders.manage_payments) | Record, edit, and delete payments and refunds, and apply or remove store credit. |
Refund (sales_orders.refund) | Show or hide the sales-credit (credit note) create and delete controls. Interface-only — see Permissions enforced in the interface only. |
Manage shipping (sales_orders.manage_shipping) | Show or hide the ship-to name/address override control. Interface-only — see Permissions enforced in the interface only. |
Export (sales_orders.export) | Export the sales orders list. |
Import (sales_orders.import) | Import orders from CSV and download the import template. |
Print (sales_orders.print) | Print packing slips and mark them as printed. |
Some sales-order actions draw on permissions from neighbouring areas:
| Permission | Grants the ability to |
|---|---|
Returns — Create (returns.create) | Create an RMA from an order (single, or a bulk action across the list). |
POS — Operate (pos.operate) | Open and close a register session, ring up sales, and open the register from an order. |
POS — Refund (pos.refund) | Process an in-store refund against a completed POS sale. |
POS — Manage (pos.manage) | Change POS settings and manage gift cards and loyalty. |
Permissions enforced in the interface only
Two of the permissions above gate their controls in the interface but aren't re-checked as that specific permission on the API:
- Manage shipping hides the ship-to name/address override control from users who lack it, but the override is saved as part of the ordinary order-edit request. That request is authorized by the Update permission, so anyone who can edit the order can also change the ship-to address through the API.
- Refund hides the sales-credit (credit note) create and delete controls, but the sales-credit API is authorized by the
orders:writetoken scope and a signed-in session — not by asales_orders.refundcheck. Anyone who can write orders can create or delete a sales credit through the API.
If you need either action blocked at the server, don't rely on Manage shipping or Refund alone — restrict the broader Update permission and the orders:write scope instead.
Action-to-permission matrix
Use this to find the permission behind any action on the sales-order surface.
Creating and editing
| Action | Permission |
|---|---|
| Create a sales order | Create |
| Edit the header, addresses, lines, discounts, or charges | Update |
| Add, map, replace, split, reclassify, or delete lines | Update |
| Add notes, tags, or custom-field values | Update |
| Duplicate an order | Update |
| Resend or exchange an order | Update |
| Generate the accounting transaction or recalculate financials | Update |
| Override the ship-to name and address | Manage shipping shows the control; Update enforces it on the API |
| Delete an order (single, bulk, or tracked) | Delete |
The per-line actions (add, map, replace, split, reclassify, delete) live inside the order's Edit mode, which the Edit button gates on Update. See View and edit a sales order and Manage order lines.
Approving, allocating, and closing
| Action | Permission |
|---|---|
| Approve or reserve an order | Approve |
| Allocate, unallocate, or reserve stock | Update |
| Mark as draft (revert an approved order) | Update |
| Archive or unarchive | Update |
| Close an order | Cancel |
| Cancel an order | Cancel |
See Approve, reserve, and allocate stock and Close, cancel, archive, and delete orders.
Fulfilling and shipping
| Action | Permission |
|---|---|
| Fulfill, bulk-fulfill, or fully fulfill | Fulfill |
| Fulfill via Amazon FBA or link an MCF fulfillment | Fulfill |
| Mark line quantities for pickup (Click & Collect) | Fulfill |
| Create a dropship request and record supplier tracking | Fulfill |
| Dispatch fulfillments to a provider | Fulfill |
| Edit, split, move, or merge a fulfillment order | Fulfill |
| Void, restore, or archive a shipment | Fulfill |
| Print or mark a packing slip as printed |
See Fulfill a sales order, Split, move, and merge fulfillments, and Void, restore, or reset a shipment.
Payments, credits, and returns
| Action | Permission |
|---|---|
| Record, edit, or delete a payment or refund | Manage payments |
| Apply or remove customer store credit | Manage payments |
| Create or delete a sales credit (credit note) | Refund shows the control; orders:write scope enforces it on the API |
| Create an RMA from the order or the list | Returns — Create |
See Record payments and apply store credit and Process returns: RMAs and credits.
List, documents, and import/export
| Action | Permission |
|---|---|
| Export the list (summary or line items) | Export |
| Import orders from CSV, or download the template | Import |
| Bulk-print packing slips | Update |
| Mark packing slips as printed | |
| Email orders to customers (single or bulk) | Update |
See Bulk actions on the sales orders list and Import sales orders.
Point of sale
| Action | Permission |
|---|---|
| Open or close a register session | POS — Operate |
| Build the cart and take payment (checkout) | POS — Operate |
| Open the register from a sales order | POS — Operate |
| Refund a completed POS sale | POS — Refund |
| Change POS settings; manage gift cards and loyalty | POS — Manage |
See Sell at the point of sale (POS).
Gates that block an action regardless of permission
Some actions can be unavailable even when your role allows them. These gates protect data integrity and cross-system consistency — they aren't permission failures.
| Gate | What it blocks | How it surfaces |
|---|---|---|
| Live edit lock | Editing an order another user is already editing | A read-only banner names the current editor; Edit is disabled |
| Channel-managed order | Cancelling an order that came from a sales channel | Cancel order is disabled with a note to cancel it in the channel |
| Warehouse lock | Changing a line's warehouse once fulfillment has started | The warehouse field is frozen on committed lines |
| Status guards | Editing a closed or fully paid order, or closing one with active backorders or unmapped lines | The action is blocked with an explanatory message |
The live edit lock
Only one person edits an order at a time. When you enter Edit mode, the order acquires a short-lived lock (renewed while you work, released when you save, cancel, or navigate away). Anyone else viewing the same order sees a read-only banner — "Jordan is editing this order. The form is read-only until they finish." — with two choices:
- Request edit notifies the current editor that you want in.
- Take over seizes the lock immediately; the previous editor's form flips to read-only and they're prompted that they've lost the lock.
The lock is about concurrency, not permission: holding Update doesn't let two people edit at once. If you open the same order in a second tab, that tab shows "You're editing this order in another tab. Saving there, or taking over here, lets you continue." — per-user multi-tab editing is last-write-wins. See View and edit a sales order.
Channel-managed orders
An order imported from a sales channel (Shopify, Amazon, WooCommerce, Faire) can't be cancelled inside SKU.io. The Cancel order action is disabled with a hint to cancel it in the originating channel; the cancellation then syncs back automatically. Other edits still follow the normal permissions above. See How channel orders sync.
The warehouse lock
A line's warehouse freezes once fulfillment begins against it, and a shipment's warehouse freezes once it has inventory movements. This holds regardless of your permissions — see Warehouse routing and the warehouse lock.
Archiving an order removes it from the working list without deleting it or changing who can act on it. Unarchive it (or clear the archived filter) to bring it back. Archiving and unarchiving both require Update.
API token scopes
If you call the sales-order API with a Personal Access Token rather than the app, a second check applies on top of permissions: the token must carry the orders:read scope for read requests and orders:write for anything that changes data. A token missing the scope is rejected with a 403 naming the required scope. First-party sessions (the SKU.io app) and integration-partner tokens aren't subject to token scopes — they're governed by the permissions above.