Roles and permissions reference
A reference for how access works in SKU.io. For the walkthroughs, see Create and manage users and Create a role.
Access levels
Every user has an access level, set with the Is Admin and Is Power User toggles on their account:
| Level | Grants |
|---|---|
| Admin | Full, unrestricted access, including settings and user management. Admins bypass all role permissions. |
| Power User | Elevated access below an admin. |
| Standard user | No elevated access — reaches only what assigned roles grant. |
Roles and the Full Access role
A role is a named set of permissions you assign to standard users. When granular permissions are enabled for your account, SKU.io seeds a Full Access role that holds every permission — so nobody loses access the moment the feature turns on. Grant Full Access as a fallback, then build narrower roles and remove it as your team moves onto scoped access.
How permissions are structured
Each permission is a category paired with an action — for example, Sales Orders → Approve or Products → Import. The Permissions tab shows the full catalog as a read-only matrix, with a column per role, so you can see at a glance which roles hold each permission.
Common actions
Most categories share the same core actions:
| Action | Meaning |
|---|---|
| Index | View the list |
| Show | View a single record |
| Create / Update / Delete | Add, edit, and remove records |
| Import / Export | Bring records in or send them out as files |
| Archive / Restore | Retire a record from use, or bring it back |
Many categories add their own actions — Sales Orders has Approve, Fulfill, Refund, and Manage Payments; Purchase Orders has Approve and Receive; Warehouse Transfers has Ship and Receive; Integrations has Sync; Financials has Recalculate.
Under a purchase order approval policy, Purchase Orders → Approve no longer decides who approves a PO: being listed on the policy does. Submit on an approved PO then needs Purchase Orders → Edit. Without a policy, Approve covers approving and submitting, including bulk Approve and Submit on the purchase orders list.
Actions that need a specific permission
Some actions sit on one screen but are checked against another area's permission, or a narrower one. Without it, the request is refused, and where the screen has a button for the action, the button is greyed out with a tooltip saying why.
| Action | Needs |
|---|---|
| Set a saved table view as the global default | Settings → Edit |
| Import sales credit lines | Returns → Edit |
| Import vendor credit lines | Purchase Orders → Edit |
| Import listing inventory settings | Listings → Edit |
| Register, refresh or re-track shipment tracking, or change its carrier | Edit on any of Fulfillment Orders, Purchase Orders, Warehouse Transfers or Returns |
| Create or revoke a 3PL connection token | Integrations → Create to create, Integrations → Delete to revoke |
| View channel partners / change them, including their tokens and mappings | Integrations → View / Integrations → Edit |
| Write off or adjust a customer's on-account balance (through the API) | Customers → Manage Credit |
| Reopen a Closed manufacturing order | Manufacturing → Reopen. Only the admin role has it by default: Full Access doesn't include it, and an admin grants it role by role. |
Categories
Permissions span the whole product, grouped by area — including Users, Roles, Settings, Products, Categories, Brands, Brand Reports, Attributes, Customers, Suppliers, Sales Reps, Sales Orders, Fulfillment Orders, Quotes, Purchase Orders, Returns, POS, Inventory, Send Planner, Warehouses, Warehouse Transfers, Reports, Integrations, Data Feeds, Accounting, Financials, Nominal Codes, Tax Rates, Payment Types, Shipping Methods, Currencies, Discount Codes, Pricing Tiers, Email Templates, PDF Templates, Approval Policies, and AI.
Approval Policies permissions
None of these lets anyone approve. Who approves a purchase order, vendor deposit or bill payment comes only from being listed on its approval policy.
| Permission | Lets a user |
|---|---|
| Approval Policies → View rules | See the approval policies (tiers, approvers and rules) for purchase orders, vendor deposits and bill payments. |
| Approval Policies → Edit rules | Change the approval policies: turn them on or off, edit tiers and approvers, reminders and self-approval rules. |
| Approval Policies → Override & re-route | Approve a stuck request on someone's behalf (a reason is required and the document is flagged), re-route requests, and manage anyone's delegations. |
Administrators can do all three. See the Approval permissions reference.
Accounting permissions for the month-end close
The month-end close uses five Accounting permissions. Each one's key is beside its label.
| Permission | Lets a user |
|---|---|
Accounting → List (accounting.index) | See the Accounting section, including the Close tab, read-only. Without this permission, Accounting doesn't appear in the navigation menu. |
Accounting → Sync (accounting.sync) | Run the close's day-to-day actions: Start close, Re-check, tick checklist items, take over preparing a month, capture provider balances and export the close pack. |
Accounting → Manage Settings (accounting.manage_settings) | Close a month, re-sign off a restated month, reopen a sign-off, change the close settings, and turn Enforce locally on or off for a provider lock. Without this permission, Accounting → Settings → Close is read-only and says so. |
Accounting → Period Override (accounting.period.override) | Close over a blocking check that allows it, with a recorded reason, and move the hard close date over months that were never closed. |
Accounting → Period Hard Close (accounting.period.hard_close) | Set, move, lower or clear the hard close date, which freezes your books. That includes Also lock through this month when closing, Use as hard close date for a provider's lock date, and locking everything before a new opening baseline. Only the admin role has it by default: Full Access doesn't include it, and an admin grants it role by role. |
Without Period Hard Close, the hard close date buttons are greyed out with the tooltip You do not have permission to move the hard close date. For every close action and what each permission unlocks, see Who can do what in the close.
Brand Reports permissions
| Permission | Lets a user |
|---|---|
| Brand Reports → Index | View brand reports, their history and each brand's reporting settings. |
| Brand Reports → Manage | Change a brand's reporting settings and core products, edit report notes, and approve, skip or regenerate reports. Also needed to approve a report while sending it, or to change its summary. |
| Brand Reports → Send | Send approved brand reports to the brand's contacts, and create or revoke their share links. Also needed to turn on automatic sending for a brand. |
Roles that could already view brands were given all three when Brand Reports arrived. Brand alerts go to everyone with Manage. See Brand Reports.
Product Lifecycle permission
| Permission | Lets a user |
|---|---|
| Products → Lifecycle | Change a product's lifecycle state (one product, in bulk, by schedule or by import), link successors, undo or reactivate, and accept, dismiss or snooze lifecycle suggestions. |
Changing the states and their rules under Settings → Products → Product Lifecycle needs Settings access instead, and clearance plans need Products → Pricing. The follow-ups you can tick when you discontinue a product, such as cancelling purchase order lines, need their own permissions. Roles that could already update products were given Products → Lifecycle when lifecycle states arrived. See Lifecycle alerts, automations and permissions.
Send Planner permissions
The Send Planner has three permissions, in the order the work happens.
| Permission | Lets a user |
|---|---|
| Send Planner → View | Open the Send Planner, read-only: working plans, send runs, scenarios, history, network rules, and the drafts made from a plan. |
| Send Planner → Edit | Calculate and promote plans, change quantities, approve send runs per network, and change network rules, sources, capacity limits and planner settings. It doesn't create drafts or allocate stock. |
| Send Planner → Draft | Create shipment drafts from a plan and allocate their source stock. |
Draft also needs the permission each destination screen needs, so a role can't do through the planner what it can't do directly:
| To | Also needs |
|---|---|
| Create FBA, AWD, WFS or FBT drafts | Integrations → Edit |
| Create warehouse transfer drafts, or allocate source stock | Warehouse Transfers → Create |
| Draft supplier purchase orders | Purchase Orders → Create |
Turning on automatic drafting for scheduled send runs also needs Draft. Roles that could already list warehouse transfers were given View when the Send Planner arrived, and roles that could create them were given Edit and Draft. For what each control does without these permissions, see the Send Planner permissions reference.
PayPal permissions
PayPal uses permissions from two categories. Integrations → List, Manage, Sync and Delete cover the PayPal accounts: viewing them (including payer names and email addresses), connecting and re-checking them, Import now, and deleting an account that never took a payment. Sales Orders → Payments covers creating, emailing and cancelling pay links, and Sales Orders → Refund covers Refund via PayPal. The full action-by-action table is in the PayPal reference.
Support Insights permission
Support Insights → Access lets a user generate, view, download and delete Support Insights reports. Admins always have it. It isn't part of Full Access and isn't given to any other role automatically, because the report names the team members who raise tickets. Turn it on for each role that should see the report.
AI permissions
| Permission | Lets a user |
|---|---|
| AI → Use | Use SKU.io's AI features: the AI Assistant, AI table filters, Report Builder AI, the AI template editor, and the document readers and other features that send data to your AI provider. Without it, those buttons are hidden and the assistant explains that the role doesn't include AI. |
| AI → View activity | Open the Activity tab under Settings → AI Assistant and export it: every AI call, who made it, which data types it involved, and whether anything was hidden or blocked. |
Admins have both. AI → Use replaced the old Access level setting (All Users / Admins Only) on the AI Assistant settings page. When it arrived, accounts set to All Users had it added to every role, and accounts set to Admins Only had it added to none. Roles that held Settings → Edit were given View activity.
AI → Use decides whether someone can use AI. What the AI can then see is the smaller of two things: what that person's role lets them see, and the data types your account switches on for AI. You can turn AI → Use on or off for each role in the role editor, or from Who can use AI on the AI Assistant settings page. See Control what the AI can see.
Report permissions
Besides Reports → List, which shows every report, a role can be given individual reports. Open the role, choose Reports under Pages & Tabs, and tick the reports it may open. A role that also has Reports → List sees every report anyway. The Dropship Performance report, in the Sales & Fulfillment group, is one of these; it shows how on time you ship retailers' dropship orders. See Track dropship performance.
Fulfillment Orders permissions
Each action on a fulfillment order has its own permission, so you can split the work between the people who prepare orders, the people who send them, and the people who ship them. The role editor lists them in the order the work happens, as in this table.
| Permission | Lets a user |
|---|---|
| Fulfillment Orders → View | See fulfillment orders, the fulfillment board, each order's activity and packing-slip history, and print or export them. Every other Fulfillment Orders permission also needs View. |
| Fulfillment Orders → Edit | Change a fulfillment order before it ships: its shipping method and provider, signature, and warehouse instructions. Also split, move, merge and unmerge orders, and apply line updates from the sales order. |
| Fulfillment Orders → Submit & sync | Send fulfillment orders to the warehouse or 3PL, retry a failed submission, and sync status to or from the provider. |
| Fulfillment Orders → Ship | Record shipments, mark orders picked up, buy shipping labels, and accept or reopen provider quantity discrepancies. |
| Fulfillment Orders → Cancel | Cancel fulfillment orders, including recalling them from the 3PL. |
| Fulfillment Orders → Administer | Use the override tools for stuck orders: force-fail a submission, and merge orders that are already at the provider. |
Suggested roles:
| Role | Permissions |
|---|---|
| Warehouse staff | View + Ship |
| Office staff | View + Edit + Submit & sync |
| Operations lead | All six |
Recording shipments and marking orders picked up on a fulfillment order need Ship, not Sales Orders → Fulfill.
A user without a permission still sees the action, but it's locked: greyed out, with a lock icon. Hovering it shows a tooltip naming the permission to ask an administrator for, such as You need the "Fulfillment Orders → Cancel" permission. Ask an admin to add it to your role. In the role editor, a role that has any of these permissions without View shows the warning These permissions have no effect without View. On fulfillment order pages, a user whose role lacks Sales Orders → List sees sales order numbers as plain text rather than links, and Manage on sales order isn't offered.
Roles that could already reach fulfillment orders were given all six when these permissions arrived: every role with a Sales Orders permission. Roles that reach fulfillment orders through the backorders page or an integration kept the actions they could already take there. Nobody lost access. To tighten a role, untick the permissions it shouldn't have. For a walkthrough, see Control who can act on fulfillment orders.
Related
- Create a role — build and assign a scoped role.
- Control who can act on fulfillment orders — a role for warehouse staff who ship but don't edit or cancel.
- Fulfill a sales order — where the Fulfillment Orders actions live.
- Create and manage users — set a user's access level and roles.
- Send Planner permissions — what each Send Planner control needs.
- PayPal reference — which permission each PayPal action needs.
- Control what the AI can see — who can use AI, and which data it may receive.
- Approval permissions reference — who can set up, approve, and override approvals.
- Who can do what in the close — which permission each month-end close action needs.