Roles and access

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

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. 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. 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, 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

​

Related