> ## Documentation Index > Fetch the complete documentation index at: https://docs.usenash.com/llms.txt > Use this file to discover all available pages before exploring further. # Roles and access > How Nash roles and feature permissions work, recommended user groups to start from, and how to keep configuration and credentials restricted. Every person in your Nash organization holds one or more roles. A role is a set of features they can read and features they can change. Nash seeds four roles when your organization is created, and you can build your own on top of them. Getting this right early is cheaper than fixing it later. Access shapes what your operators see on a busy morning, who can change dispatch behavior mid-peak, and how quickly someone loses access when they leave. ## How access works Access is granted by **feature**, not by individual screen. Each feature has a read side and a write side: read lets someone see it, write lets them change it. Granting write always carries its matching read, so a role with write access to a feature can always see that feature too. The features you assign to a role are: Analytics, Monitor, Deliveries, Batch Jobs, Dispatch Strategy, Optimization Strategy, Route Monitor, Delivery Windows, Shifts, Zones, Store Locations, Store Inventory, Products, Templates, Notifications, Webhooks, Workflows, Nash Agent, Billing, Organization Management, Organization Roles, and User Management. Two consequences worth knowing before you design roles: * **Roles are additive.** Someone with two roles gets the union of both. There is no deny rule that claws access back, so you reduce access by removing a role, not by adding a narrower one. * **Roles are per organization.** If your operation spans several Nash organizations, a person's access in one says nothing about their access in another. ## The default roles | Role | What it covers | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Owner** | Every feature in the organization, read and write. | | **Admin** | Every feature in the organization, read and write. | | **Operations** | The delivery day: create and act on orders and deliveries, plus read access to history, tracking, analytics, monitor, store locations, and optimization strategies. No configuration access. | | **Billing Admin** | Everything Operations covers, plus read and write on Billing. | Two things surprise people: **Owner and Admin carry the same permissions.** Choosing Admin instead of Owner does not reduce what someone can do. If you want a lesser administrator, build a custom role rather than assuming Admin is one. **Billing Admin is not billing-only.** It is Operations plus Billing, so it can also act on live deliveries. If your finance team should only see invoices, give them a custom role with Billing alone. ## Recommended user groups A structure that holds up in most operations. Start from the group that matches the job, then add features by exception rather than by default. | Group | Who is in it | Start from | Add | | -------------------------- | ---------------------------------------------------- | ----------- | ------------------------------------------------------------------------ | | **Delivery operations** | Dispatchers, store and depot teams, customer service | Operations | Nothing. This is the majority of your users. | | **Operations lead** | Duty managers who tune behavior during the day | Operations | Write on Dispatch Strategy, Delivery Windows, Shifts, and Zones | | **Integration engineer** | The people who own your API integration | Custom role | Write on Webhooks and Templates, read on Deliveries and Notifications | | **Finance** | Invoice and cost review | Custom role | Billing only | | **Access reviewer** | Security or IT confirming who has what | Custom role | Read on Organization Roles, User Management, and Organization Management | | **Platform administrator** | The few people who configure Nash | Admin | Nothing. Keep this group as small as it can be. | Name roles after the work rather than after seniority, so the next person to join maps cleanly onto one. "Depot dispatcher" and "Finance review" age better than "Level 2". ## Restricting configuration and credentials Two controls come up in almost every security assessment. **Webhook configuration.** Webhooks are their own feature, and the stock Operations role does not include it. Anyone on Operations can work the delivery day without being able to see or change where Nash sends your events. Give write on Webhooks only to the group that owns your integration, and keep read on it for anyone who needs to debug delivery of events without changing endpoints. **API key visibility.** Keys belong to the person who created them. A user sees only their own keys; listing every key in the organization is restricted to Owner and Admin. A key's secret is shown once at creation and never again, so it cannot be recovered from the Portal by anyone, at any access level. A key also carries its own feature grants and can never exceed the access of the user who created it, so a key made by someone on Operations cannot reach Billing or Webhooks no matter which features are ticked. See [API key and Org ID](/reference/generating-api-key-and-org-id). If your security team needs both restrictions in writing: webhook configuration is gated by the Webhooks feature, and organization-wide key visibility is limited to the Owner and Admin roles. ## Best practices **Start everyone on Operations.** It covers the delivery day without exposing configuration. Most people in a logistics operation never need more, and starting narrow means access grows by request instead of by default. **Separate running the day from changing the rules.** Dispatch Strategy, Optimization Strategy, Workflows, Webhooks, and Notifications decide how the system behaves for every order that follows. Keep write access to those with a small, named group. Reading them is different: dispatchers benefit from seeing which strategy is in play, so read access is usually worth granting widely. **Count your Owners and Admins, then cut the number.** Full access is the right answer for a handful of people who configure the platform, and the wrong answer for anyone who was given it once to unblock a launch. Revisit the list after go-live, while the temporary grants from launch week are still recent enough to explain. **Let your directory drive it.** With [single sign-on](/reference/single-sign-on), your identity provider groups map to Nash roles, so a change in your directory shows up in the Portal on the next sign-in. Joiners and leavers become a directory operation rather than a Nash one, which removes the drift that builds up when both sides are maintained by hand. **Set the least-privileged role as your default.** New users provisioned through SSO land on your organization's default role before anyone reviews them. Make that the narrowest role you have, not a convenient one. **Keep API keys on their own budget.** One key per integration, scoped to what that integration does, so you can rotate or revoke one without taking down the rest. **Re-check access when the operation changes shape.** A new region, a new fulfillment model, or a team reorganization usually needs a new role, not a wider existing one. Widening the role everyone already holds is the quiet way an organization ends up with fifty administrators. ## FAQ Yes. A custom role is any set of features with read or write on each, so you can build a dispatcher who cannot change strategies, or a finance reviewer who sees only Billing. Nash's default role names (Owner, Admin, Operations, Billing Admin) are reserved and cannot be edited or reused, which keeps a stock role from quietly meaning something different in one organization. Someone with write access to User Management and Organization Roles, which in practice means an Owner or Admin. Keep that list short: it is the access that can grant every other kind. No. Users see their own keys. Listing every key in the organization is limited to Owner and Admin, and no role can reveal a key's secret after creation. If you use SSO, remove them in your identity provider and they can no longer sign in; the Nash user is deactivated rather than deleted, so their past actions stay attributed. Without SSO, remove their access in the Portal. Either way, check for API keys they created, since a key outlives the browser session. Both. Roles combine, and the person gets everything either role allows. To reduce what someone can do, take a role away rather than adding a narrower one. Talk to your Nash contact about how to scope this for your operation. The right shape depends on how your organizations and store locations are set up, so it is worth a conversation before you build roles around it. ## Related Connect Portal sign-in to your identity provider and map your groups to Nash roles. Create a key in the Portal, scope it to features, and find your Org ID. How API requests authenticate, and why keys are separate from people.