Which records each user can see
Every portal user sees only the records of their own organisation. Merchant Supervisors see only their assigned stores in store and order lists. A record of another organisation answers with a not-found page, as if it did not exist.
Overview#
Access is decided in two independent steps. Your role decides which features and actions you may use, as listed on What each role can do. Your organisation then decides which records those features show you: a permission unlocks a feature, never another organisation's rows. The same filtering applies to the portal pages, their Excel exports and the API. This page covers portal users. Drivers sign in to the Driver App without a portal role; see Roles and permission groups.
Rules#
| Viewer | Records they see |
|---|---|
| Tenant Owner, Admin, Supervisor, Accountant | All records of their own tenant: vehicles, drivers, orders, users and so on, with no narrowing by user or vehicle |
| Merchant Owner, Admin, Accountant | All records of their own merchant, across all of its stores |
| Merchant Supervisor | The records of their merchant, but in the store list and the order lists only the stores they are assigned to |
| Platform team accounts | The records of every tenant and merchant. This reach comes with a platform team account, not with the Platform Operator role alone |
- Supervisors are not a level in a hierarchy. A Tenant Supervisor sees exactly the same tenant records as a Tenant Owner; only the actions differ.
- A user's department is shown on their profile but does not narrow what they see. Everyone in a tenant sees the whole tenant's fleet, whatever their department.
- A Merchant Supervisor with no store assigned sees an empty store list and no orders, never all stores.
- A change of role takes effect on the user's next request. They do not have to sign out and back in.
- A user who belongs to neither a tenant nor a merchant, and is not a Platform Operator, sees no organisation records.
Who sees which order, and what each side is shown of the other, is on Who sees and is notified about an order. Finance pages follow the same organisation rule; see Who can see and do what in finance.
What tenants see of merchants#
Tenant users also see some records that belong to merchants, limited to the merchants they can actually buy from:
- Stores. A tenant sees the stores it can use, and nothing else. Which stores those are is explained on Which stores tenants and drivers can see.
- SKUs, services and prices. All four tenant roles may read the SKUs, services and prices of the merchants behind those stores, plus services available platform-wide. Tenants read them through the API and the in-app assistant. The Services, SKUs and Price Lists pages of the portal are merchant pages, and a tenant user who opens one gets an access-denied page.
- Voucher pools and campaigns. Tenant Supervisors and Accountants, like Owners and Admins, may read voucher pools granted to their own tenant and their own tenant's campaigns. Voucher redemptions are merchant-side records; tenants never see them.
- No internal detail. A tenant never sees the change history of a merchant's store, SKU, service or price, even where it can see the record itself. On a store it sees the public details and prices, never the store's notes, activity timeline, today's orders, devices or assigned staff. What the history records, and who reads it, is on Audit log.
- Read access never becomes write access. Tenants cannot create, change or delete a merchant's SKUs, services or prices. Store pages show tenants no price-editing actions, and a tenant who reaches the price review of a store directly is refused.
When a record is out of scope#
| Situation | Answer |
|---|---|
| You open a record of another organisation, for example by its link | A not-found (404) page, the same answer as for a record that does not exist, so its existence stays hidden. This holds for reading, changing and deleting |
| Your role lacks the permission for the feature or action | An access-denied (403) page |
| A tenant user tries a merchant-side change, such as editing a store, SKU or price over the API, or a merchant user opens a tenant-only feature such as vehicles or drivers | Access denied (403), not an empty list. Tenant reads of SKUs, services and prices are allowed and scoped, as above. |
| You try an action that belongs to the other side of an order you can see, such as a merchant confirming for the tenant | Access denied (403) |
| A tenant user holds a stray write permission on a merchant's price or SKU | On the portal's edit pages, not found (404), because the record is not in their writable scope; over the API, access denied (403). Either way the change cannot happen |
Edge cases#
- Merchant Supervisor and direct links. Store assignment narrows the store list, a store's change history, and the portal's order lists and order pages. A store's detail page, and an order opened by its reference over the API, are scoped to the whole merchant, so a Merchant Supervisor can open them for any of the merchant's stores.
- Tenant with no country. A tenant whose record has no country sees no partner stores, SKUs or prices.
- Catalog pages for tenants. A tenant user gets an access-denied page on the Services, SKUs and Price Lists pages for every row, whether or not the row is in its scope, so the answer reveals nothing.
- Inactive records. Merchant users still see their own inactive stores, SKUs and services so they can reactivate them. Tenants see only active ones.