> ## Documentation Index > Fetch the complete documentation index at: https://docs.tryoto.com/llms.txt > Use this file to discover all available pages before exploring further. # Users, roles & permissions > Add users, define role templates and permissions, limit people to specific hubs, remove leavers, and set password and two-factor authentication rules. Access in OTO answers two questions separately: what kind of user is this, and what is that particular person allowed to do. Getting the first right takes a moment; getting the second right is what stops a picker seeing your margins. ## The two layers | Layer | What it decides | | - | - | | **User Type** | What kind of account this is, and which part of the product it belongs to. Set when the user is created. | | **Permissions** | Which pages and actions that account can reach — applied from a **role template**, and adjustable per person. | ### User types | Type | Who it is for | | - | - | | **Company Admin** | Full administrative access to the account. | | **Warehouse User** | Works inside a warehouse, in [OTO PACK](https://docs.tryoto.com/modules/warehouse-management/overview.md). Scoped to the hubs they are assigned to. | | **Branch User** | The same, for a shop that also fulfills orders. See [Hubs Management](https://docs.tryoto.com/modules/hubs-management/overview.md). | | **Driver User** | A driver on your own fleet, working in the [OTO FLEX](https://docs.tryoto.com/modules/oto-flex/overview.md) app rather than the dashboard. | | **Customer Service User** | Answers “where is my order”. Needs order visibility and usually nothing else. | | **Brand Manager User** | Responsible for one brand within a multi-brand account, rather than for the whole business. | ## Role templates A role template is a named set of permissions you define once and apply to as many people as you like, at **Settings → Management → Role Templates**. The list shows each template and **how many users currently hold it**, which is the number to look at before you change one. **Add Template** asks for a name and then presents the permission tree. It has three columns — **Name**, **Type** and **Permission** — and a search box, which you will want: the tree covers **22 top-level areas**, from Shipments and Dashboard through Warehouses, Payments, OTO FLEX and Customer Service to Profile Settings. ### Pages and actions Every permission is one of two kinds, and the distinction is the useful part. | Type | What granting it means | | - | - | | **Page** | This person can *see* this screen. | | **Action** | This person can *do* this specific thing on it. | The tree nests, so permissions get more specific as you go down. **Shipments** is a page; inside it **Pending Orders** is a page; inside that, **With My Rates** and **Edit Order Admin** are actions. Warehouses breaks down the same way into **Add**, **Edit**, **View** and **Activate/Deactivate**. > [!TIP] > > **Separating seeing from doing is what makes least privilege practical** > > Without it, access is all-or-nothing per screen, and the path of least resistance is to grant the whole screen to anyone who needs any part of it. > > With it, a customer-service agent can open an order and read its history without being able to edit it, cancel it or see what it cost you. That is the difference between a role you can hand out freely and one that needs a conversation first. ## Assigning and adjusting On the **Users** screen, the **Roles** menu carries three operations, and they do different jobs. | Operation | What it does | | - | - | | **Apply Role Template** | Give this person a named template. The normal path, and the one to prefer. | | **Modify Roles** | Adjust this one person's permissions away from their template — for the genuine exception. | | **Restore Roles** | Discard those adjustments and put the person back on default permissions. | A user holds **one role template at a time**. There is no stacking of templates, which keeps “what can this person do” answerable by looking in one place. > [!NOTE] > > **Has Custom Role is the column that keeps this honest** > > The user list carries a **Has Custom Role** flag showing everyone whose permissions no longer match their template. That is the audit answer to the question every access review asks. > > Permission drift is undramatic and cumulative: someone needs one extra action for one busy week, it is granted individually, and nobody takes it away. Filtering on this column periodically — and using **Restore Roles** on anyone whose exception has expired — is a five-minute habit that prevents a long afternoon before an audit. ## Adding a user **Settings → Management → Users → Add User**. | Field | Notes | | - | - | | **Full Name** | Required. | | **Mobile Number** | With country code. | | **Email** | Where the invitation goes, and the sign-in identity. | | **User Type** | One of the six above. | | **Job Title** | Optional. | | **User Code** | Optional. Useful for matching people to records in an HR or ERP system. | | **Photo** | Optional. | On save, an invitation email goes out carrying a password reset link, and the new user chooses their own password. Nobody sets a password on someone else's behalf, and no password travels by message. If the invitation is lost, an administrator can send the link again from the user's **Tools** menu rather than issuing a password. ## The user list | Column | What it tells you | | - | - | | **Full Name** · **Email** · **Phone** | Who they are. | | **User Type** | Which kind of account. | | **Role Template Name** | The template they hold. | | **Has Custom Role** | Whether they have been adjusted away from it. | | **User Code** | Your own identifier, if you set one. | | **Status** | Active or deactivated. | | **2FA Status** | Whether this person has two-factor authentication turned on. | Every column filters, so “who has admin access”, “who is not on a template” and “who has no second factor” are all one filter away. > [!TIP] > > **Run the 2FA filter before anyone asks you to** > > A security questionnaire will eventually ask what proportion of your users have multi-factor authentication enabled. This column is the answer, and it is better discovered on a quiet Tuesday than during a procurement review. ## Leavers Users are **deactivated, not deleted**. **Tools → Deactivate User** revokes access immediately; **Activate User** restores it. > [!NOTE] > > **Not deleting people is the correct behavior, not a limitation** > > Orders, shipments, picks and status changes carry the identity of whoever performed them. Deleting the person would either break those records or quietly detach them, and a fulfillment history you cannot attribute is not much of a history. > > Deactivation ends the access and keeps the trail. When someone leaves, deactivate the account *and* regenerate any API credential they had access to — the refresh token does not expire on its own. See [API authentication](https://docs.tryoto.com/developers/authentication.md). ## Scoping people to places Beyond permissions, warehouse and branch staff are scoped to the sites they actually work in. | | | | - | - | | **Accessible Users, per hub** | Each warehouse or branch names the users who may work in it, set when the hub is created or edited. See [Hubs Management](https://docs.tryoto.com/modules/hubs-management/overview.md). | | **OTO PACK users and teams** | **OTO PACK → Configuration** carries its own **Users** and **Teams** tabs, which is where picker teams are formed for wave and zone picking. | The effect is that a picker at one site sees one site's queue. Scope and permission are different controls and both apply: a permission says what kind of work someone may do, and scope says where. ## Passwords and two-factor authentication Each person manages their own credentials at **Settings → My Profile**. | | | | - | - | | **Password policy** | At least 8 characters, with an uppercase letter, a lowercase letter and a number. | | **Two-factor authentication** | Time-based codes from an authenticator app. Enabling it shows a QR code and a manual key; you confirm with a six-digit code. | | **Backup codes** | Generated when 2FA is enabled, and the way back in if the phone is lost. | | **Passkey** | Sign in without a password at all, using the device's own authentication. **Enable Passkey** sits beside the other two. | > [!TIP] > > **Passkeys are the stronger option where the device supports them** > > A passkey cannot be phished, because there is no code to read out and no password to type into a convincing imitation of the login page. It is the one authentication change that removes a whole category of attack rather than making it harder. > > It is worth offering to administrators and anyone with financial visibility first, since those are the accounts an attacker would want. > [!TIP] > > **Authenticator codes rather than SMS, and store the backup codes properly** > > App-generated codes are not vulnerable to SIM swapping or to an intercepted message, which is why they are the method here. > > The trade-off is that a lost phone locks the person out, and the backup codes are the only way back. Saving them into a password manager at the moment 2FA is enabled takes a few seconds; recovering an account without them does not. ## Related * [Security & compliance](https://docs.tryoto.com/platform/security-and-compliance.md) — the controls behind all of this, and what is certified. * [API authentication](https://docs.tryoto.com/developers/authentication.md) — how machine access is scoped and expires. * [Hubs Management](https://docs.tryoto.com/modules/hubs-management/overview.md) — assigning users to sites. * [Warehouse Management](https://docs.tryoto.com/modules/warehouse-management/overview.md) — picker teams in OTO PACK. ## Related topics - [Core concepts: orders, shipments, stock and hubs](https://docs.tryoto.com/get-started/core-concepts.md) - [Security & compliance](https://docs.tryoto.com/platform/security-and-compliance.md) - [Plans, pricing and add-ons](https://docs.tryoto.com/pricing/plans-and-packaging.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.