> For the complete documentation index, see [llms.txt](https://docs.in8sync.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.in8sync.com/client-admin-guide/managing-users/access-control.md). # How Access Works The four layers of access control in SphericalBRM + POS — subsidiary, workflow, module, and component — and how to use each. Access in space.vars.productName flows from broad to narrow. A user's role determines their workflow; their workflow determines their pages; each page can further restrict what they see and do. Understanding the four layers makes every access decision easier. ## The four layers ``` Subsidiary access → Workflow access → Module access → Component restrictions ``` Each layer narrows the scope of what a user can see.

Layer	What it controls
Subsidiary	Which business entities and their data the user can reach.	#subsidiary-level-access
Workflow	Which pages exist for this user — based on their role.	#workflow-level-access
Module	Whether each page is visible in navigation, hidden, or conditional.	#module-level-access
Component	Fine-grained restrictions on individual page elements.	#component-level-restrictions

## Subsidiary-level access The subsidiary on a user record decides which business entity's data they can see. * **Single-subsidiary** — every user is on the same subsidiary; nothing extra to configure. * **Multi-subsidiary** — users assigned to a subsidiary only see data, catalogs, and transactions from it. When a user has access to multiple subsidiaries, the **Subsidiary selector** in the top bar lets them switch. Switching changes the data context — catalogs, inventory, transactions, and reports update. ## Workflow-level access The workflow attached to the user's role defines their entire portal: * **Which pages exist** — if the workflow has no Reports module, the user can't reach Reports. * **What each page looks like** — the layout, components, and behaviour. * **What actions are available** — driven by the components on each page. To restrict access at this level, use **separate workflows for separate access levels**, then assign each to the right role. **Example:** *Cashier* uses a workflow with Dashboard, Order Form, Catalog. *Manager* uses a workflow with all of those plus Reports and User Management. ## Module-level access Within a workflow, individual modules can be: * **Visible** in navigation. * **Hidden** from navigation but reachable via direct link. * **Conditional** — visible based on a condition (a session variable, a user attribute, etc.). Use module-level controls when most users with a role need a page but a small subset shouldn't see it. ## Component-level restrictions The deepest layer. Individual components on a page can enforce additional restrictions: * **PIN override** — sensitive actions ask for a PIN before they execute. See [PIN Override](/client-admin-guide/workflow-builder-overview/pin-override.md). * **Data filtering** — components can be configured to show only data scoped to the user (their transactions, their location, their subsidiary). * **Conditional visibility** — components appear only when a condition is met (a variable has a value, a threshold is hit). * **Item access** — users can be granted or denied access to specific items in a catalog. Use this when different users need to see different product ranges or when you need to lock certain items to specific people. ## Practical patterns

Role hierarchy (most access to least)

``` Admin — full access Manager — operations + reports Supervisor — operations + limited reports Staff — basic operations only ``` Each level uses a workflow with fewer pages or more component-level restrictions.

Customer portal tiers

* **VIP Customer** — special pricing, priority support, full catalog. * **Standard Customer** — standard pricing, full catalog. * **Limited Customer** — standard pricing, restricted catalog. Build different workflows with different catalog configurations and page layouts, then assign each to the right customer role.

Department-based access

* **Sales** — order form, catalog, customer management. * **Warehouse** — inventory, receiving, transfers. * **Finance** — reports, reconciliation, billing. * **Management** — all of the above plus analytics.

## Best practices * **Least privilege.** Cashiers don't need reports. Customers shouldn't see internal pricing. Vendors should only see their own purchase orders. * **Review regularly.** Revoke access immediately when someone leaves. Re-check role assignments quarterly. * **Use PIN override for actions with financial impact** — refunds, voids, manual price changes. * **Lean on workflow-level access first**; reach for component-level restrictions only when you can't get the right outcome by changing the workflow. ## Related


Roles & Permissions	Create and manage the role library.	Roles & Permissions
Workflow Builder	Build the workflows that roles link to.	Workflows
PIN Override	Component-level authorization for sensitive actions.	PIN Override