# Managing Users 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). ## 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.	/pages/90JTHrYiNFq2sGVsSqGI
Workflow Builder	Build the workflows that roles link to.	/pages/mLgK2JGhOVvPaMyi0m1U
PIN Override	Component-level authorization for sensitive actions.	/pages/ZB1p1C3xoZi8Tr9w4b1S

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.in8sync.com/client-admin-guide/managing-users/access-control.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.