Being redirected is not the same as being refused, and the app does both without explaining which just happened.
You clicked a link, or typed an address, and ended up somewhere you did not choose. There are three separate reasons that can happen. They look the same, they have different fixes, and treating one as another is how people spend an afternoon asking for a permission that was never the problem.
- Cause 1: your role does not have the permission
- Cause 2: your role is mobile-only
- Cause 3: you are on a phone
- Telling cause 2 and cause 3 apart
- Asking an admin to grant it
Start by asking where you landed. A no-access screen is cause 1. The mobile home screen is cause 2 or cause 3. The sign-in screen is neither — your session expired, or the account was deactivated.
Cause 1: your role does not have the permission
A permission is a named key, like a key on a keyring. Pages and buttons ask for one by name.
The important part: keys are held by your role, not by you. Everyone with the same role has exactly the same keys. When a page asks for a key your role does not hold, you are redirected to a no-access screen rather than shown an empty page. That is intentional — a page that half-loads is worse than one that refuses.
There are 33 keys in total, organised into groups by area: products, purchasing, inventory, stock counts, transfers, assembly, production, sales and channels, users, settings, and utilities. You do not need to memorise them. The permission each article's action needs is named on the article itself, and the full list is kept in one place. The permissions reference
Three variations on cause 1 that look different but are the same thing:
- Settings and integrations have their own rule. Admins reach every section. A few other roles are allowed into specific sections only, and everyone else is turned away at the door — even from a section they could describe perfectly well.
- A download that saves a tiny file. If a download produces a small text file instead of your data, open it. It says either that your session expired or that you lacked permission, which are different fixes.
- A form that shows a message instead of saving. Forms deliberately do not redirect, so whatever you typed stays on screen. Read the message: expired session, deactivated account, or missing permission.
Cause 2: your role is mobile-only
Two roles are built for the warehouse floor and only exist there: warehouse staff and production supervisor.
For those two, every desktop page in the app redirects to the mobile app, before the page is even considered. It is not a refusal and it is not a missing permission. Granting a permission will not change it, because the redirect happens first and never asks about permissions at all.
This is a design decision, not a fault. The floor roles do one job each — receiving stock, counting it, confirming transfers, executing assembly, recording production output — and every one of those is a mobile screen, done standing up, one-handed. There is no desktop version to send them to.
Help pages are the deliberate exception. They are readable by anyone, on any device, signed in or not — so a link to an article always opens, even for a mobile-only role on a desktop browser.
Cause 3: you are on a phone
Any phone or tablet is sent to the mobile app, whatever your role.
The app looks at the device, not the person. An admin opening a desktop page on a phone gets exactly the same redirect a warehouse user does. The check runs after the role check, so on a phone it is the last word.
If you need a desktop page and you are holding a phone, the answer is a computer. There is no setting for this and no permission that overrides it.
Telling cause 2 and cause 3 apart
From inside the mobile app, the two are indistinguishable. One test separates them.
Open the same link on a desktop computer, signed in as yourself.
| What happens on desktop | Cause | What fixes it |
|---|---|---|
| The page opens normally | Cause 3 — the device | Use a computer for that page |
| Still bounced to the mobile app | Cause 2 — the role | Nothing; the role is mobile-only by design |
| You land on a no-access screen | Cause 1 — the permission | An admin grants the key to your role |
| You land on the sign-in screen | Neither | Sign in again, or ask whether the account was deactivated |
Do the test before you raise it with anyone. It converts "the link doesn't work" into one of four sentences that can actually be acted on.
Asking an admin to grant it
Only cause 1 is grantable, and only an admin can do it. Roles and the keys they hold are configured under Settings, in the roles section. Settings
Say four things when you ask:
- The page or button you were trying to reach.
- What you were trying to do there, in one sentence.
- Your role.
- That you already tried it on a desktop computer, and what happened.
The fourth one saves the most time, because it rules out both redirects before anyone starts looking.
Two things worth knowing before you ask. A granted key applies to everyone with your role, so the question an admin has to answer is "should every person in this role be able to do this?" — not "should you?". If the answer is only you, the right move is a new role rather than a wider one, and admins can create roles. And some roles cannot be given desktop access at all, however the permissions are set, because of cause 2.
Explore
What every permission key means. The full list, grouped by area, with what each one unlocks. Learn more →