07. Permissions Matrix

The Permissions matrix controls what each user can see and do in Qoblex. It appears as a section titled Permissions (“Choose what this user can view and manage.”) whenever you create a user or update an existing one.

This article explains how the matrix is organized, what each checkbox grants, how granting or removing a permission at a parent level flows down to everything beneath it, and what happens if you save a user with no permissions at all. After reading it you will be able to give each team member exactly the access their job needs, and troubleshoot why someone cannot reach a page or action.


How the matrix is organized

The matrix is a tree with three levels:

  1. Permission groups — the top-level rows (for example Dashboard, Stock Control, Reporting).
  2. Sub-resources — finer areas inside some groups (for example Purchase Orders under Stock Control).
  3. Action checkboxes — the actual access you grant on a row. Today almost every row offers a single View action; Purchase Orders is the only row that also offers an Approve action.

Each group row shows an access summary — No access, Partial access, or Full access — and a count of how many of its actions are currently granted (for example 2/5), so you can see at a glance how much access a group carries.

About the Purchase Orders Approve action: most rows grant View access only — the right to see that part of Qoblex. Purchase Orders also shows an Approve checkbox, but Qoblex currently records this setting without using it to gate the purchase-order approval workflow. Granting or withholding Approve does not, on its own, change who can approve a purchase order today. Set it to reflect your intent, but do not rely on it as an access control yet.


The permission groups

These are the groups in the matrix, top to bottom, with their sub-resources:

  • DashboardSales Metrics, Purchases Metrics, Inventory Metrics.
  • Inventory.
  • Stock ControlPurchase Orders (View and Approve), Adjustments, Transfers.
  • SalesSale Orders.
  • Manufacturing.
  • ContactsSuppliers, Customers.
  • Users & Access Management.
  • IntegrationsShipStation.
  • Partnerships.
  • Account Settings.
  • ReportingSales Reports, Inventory Reports, Purchase Reports.
  • System & Users Activity.

The matrix may also show Analytics and Forecasting group rows. These areas are not covered by this help set; grant View on them only if your team uses those screens.

Access to the Users page itself — where you create, invite, and edit users — is the View action on the Users & Access Management group. A user without it cannot open the Users page.


Expanding and collapsing groups

  • Click anywhere on a group row to expand it and reveal its actions and sub-resources, or click again to collapse it. The arrow on the right of the row points down when the group is open and right when it is closed.
  • A single button in the top-right of the matrix toggles every group at once. It reads Expand all while any group is collapsed, and Collapse all once all groups are open.

Granting a permission

  1. Expand the group you want to set.
  2. Select the checkbox beside the action you want to grant (for example View Sale Orders, or Approve under Purchase Orders).
  3. Clear the checkbox to remove that access again.

You can also act on a whole group at once:

  • The checkbox on the group row grants or removes every action in that group, including its sub-resources. It shows a tick when the whole group is granted, and a dash (partial state) when only some of it is.
  • Select all permissions, the checkbox at the very top of the matrix, grants every permission in every group. Clear it to remove them all.

Select all permissions is powerful: it grants access to high-impact areas including Users & Access Management, Integrations, Account Settings, and Reporting. Use it only for users who genuinely need full access.

When only some actions in a group are granted, the group checkbox shows the partial (dash) state and the summary reads Partial access — the user can do some things in that group but not everything.


How parent and child permissions flow together

Permissions inherit down the tree. This keeps a user’s access consistent and saves you from ticking every child by hand.

  • Granting a group grants its children. Turning on a group (or a parent row) turns on the matching action for every sub-resource beneath it. For example, granting Stock Control also grants View on Purchase Orders, Adjustments, and Transfers.
  • Removing it at the parent removes it down the tree. Clearing a parent action clears that same action on all of its children, and Qoblex will not let you tick a child action while its parent denies it — the parent must be granted first.

What you set on a parent always wins on save. If a parent action is turned off when you save the user, Qoblex forces the matching action off on every child beneath it, even if a child box looked ticked. Grant the parent first, then fine-tune the children.

Because of this, the safe way to give partial access inside a group is to leave the group itself partially granted: grant the specific sub-resources the user needs rather than granting the whole group and then trying to switch individual children off.


Saving a user with no permissions

If you save a user without granting any permission anywhere, Qoblex does not block you — it opens a Confirm Creation dialog warning: “This user will have no permissions in Qoblex. They won’t be able to see or do anything until they are assigned permissions.” Confirm to create the user anyway, or cancel to go back and grant access first.

This is useful when you want to stage a user record before deciding their access, but a user with no permissions cannot see or do anything until you assign some, so it is not appropriate for an active team member who needs to work in Qoblex.

Permission changes take effect for the user’s session. After you change someone’s permissions, ask them to refresh the page, or sign out and back in, before testing their access.


Matching access to the role

Before saving, match the permissions to what the person actually does:

  • Warehouse staff usually need Inventory and Stock Control (Adjustments, Transfers).
  • Purchasing staff need Purchase Orders View. (Purchase Orders also has an Approve action; see the note above on its current behavior before relying on it.)
  • Sales staff need Sales / Sale Orders and Contacts (Customers).
  • Finance staff may need Reporting and Integrations visibility.
  • Administrators typically need Users & Access Management, Integrations, and Account Settings.

Grant the narrowest set that lets the person do their job, and review it when their role changes.


Troubleshooting

A user cannot see a page or section
Confirm the user has View access on the relevant group. Because permissions inherit downward, also check that the group above it is granted — Qoblex forces a child action off whenever its parent action is off, so a sub-resource will stay hidden if its parent group is not granted.
Granting “Approve” on Purchase Orders does not change what the user can do
The Approve action on Purchase Orders is recorded on the user but is not currently used to gate the purchase-order approval workflow, so granting it does not by itself let someone approve orders, and removing it does not block them. Purchase-order approval is handled separately from this checkbox. Set Approve to record your intent, but treat it as not yet enforced.
A user cannot open the Users page
Opening the Users page requires the View action on Users & Access Management. Grant that group, then ask the user to refresh or sign back in.
A user cannot reach a report
Reporting is split into Sales Reports, Inventory Reports, and Purchase Reports. Grant the specific report area the user needs, or grant the whole Reporting group to give all three.
A child permission will not turn on
Qoblex blocks ticking a child action while its parent denies that action. Grant the parent group (or the parent row) first, then set the child.
A permission looked ticked but was not saved
On save, any parent action that is turned off forces the matching action off on every child beneath it. If a child box appeared ticked under a denied parent, grant the parent first, then save again.
The new user has no access at all
Check whether the user was saved through the Confirm Creation “no permissions” warning. A user created with no permissions cannot see or do anything until you open the user and grant access.
Was this article helpful?

Related Articles