Roles and permissions

What a person can do in SaleSprint is decided by three things at once, and all three have to agree. A role grants a permission, the subscription tier has to allow it, and the location the person is working at must not have taken it away.

what you can do  =  (your roles)  ∩  (your plan's tier)  −  (denials at this location)

Miss any one of those and the control simply is not there.

Permissions

A permission is a dotted key naming a thing and, often, an action on it — catalog.product.create, sales.quotation. There are around 200 of them, organised into roughly two dozen groups that line up with the areas of the product.

Each permission also declares where it can be used: inside a business account, on the platform operator’s side, or both. The catalogue itself lives in code and is rebuilt on every deployment, so permissions cannot drift — but the grants you have made survive that rebuild, because they refer to permissions by name.

Roles

A new account starts with exactly one role: admin, holding the complete set of permissions, assigned to the person who signed up. There is no library of starter roles — Cashier, Manager and so on are roles you create yourself.

That is deliberate, but it does mean the second user you add is a decision, not a default: you design the role before you can assign it.

admin is a system role and cannot be deleted. Roles you create can be edited and removed freely.

Where

Administration → Users, Administration → Roles

Plan

Growth and above

Permission

Administration → User, administration → Role

The same group also holds IP whitelist rules and manager PINs.

How to create a role

1. Go to Setups → Administration → Roles.
2. Click New role.
3. Type a Role name, for example Cashier.
4. Click Save.

The Default role and Public role switches do nothing

Default role suggests the role is given to every new user automatically. It is not — nothing reads the setting. A new user gets exactly the roles you tick on their own form, and a user created with none has none.

Public role is equally inert. Both are stored and never acted on, so leave them alone and assign roles explicitly.

How to give a role its permissions

1. On the role’s row, open the ⋮ menu and click Permissions.
2. Pick an area from the Groups list on the left. Each shows how many are granted.
3. Tick what the role should have. Ticking a child ticks its parents automatically; unticking a parent clears everything beneath it.
4. Use the action chips — Create (7), Edit (4) and so on — to grant or revoke a whole verb across the group at once.
5. Click Save permissions.

Search by the internal name, not the label

The Filter permissions box matches the underlying key, not the readable label. Typing “Allow Layaway” finds nothing; typing “layaway” works.

How to assign a role to someone

1. Go to Setups → Administration → Users.
2. Click New user, or Edit an existing one.
3. In the Roles section, tap the chips for the roles they should have.
4. Click Save.

To give one person something extra without changing the role, use ⋮ → Manage permissions. Permissions coming from a role show as From role and are locked; you can add Direct ones, or use the red ✗ to deny one for that person only.

One filter on the users list does nothing

The Active/Inactive filter has no effect — the list ignores it.

How the tier interacts

Permissions are additionally gated by subscription tier, and the two combine as and, never or.

So a role can perfectly well grant sales.quotation to someone on a plan below Growth — and that permission is silently stripped from what they can actually do. The grant stays ticked in the role editor; the user simply never sees the feature.

If someone insists they have been given access and the screen is still missing, check the account’s plan before you check the role. See Plans and what they unlock.

Denials at a location

Location assignments work as a whitelist plus subtraction. A user must be assigned to a location before they can do anything there at all. Once assigned, an administrator can only take permissions away at that specific location — never add them.

This is the tool for “she is a supervisor, but not at the downtown branch”. A denial set at company level cascades to every location under it, and any denial can be given a start and end date, which covers “revoke this for the next fortnight” without anyone having to remember to put it back.

Denials are checked live on every request rather than cached, so adding or lifting one takes effect immediately — faster than a role change.

When a change reaches the user

A user’s permissions are computed once and cached, so a role change is not instant everywhere. It reaches the affected person:

• Near-instantly if their device receives the push that tells it to refresh;
• otherwise within five minutes, on the background refresh;
• or immediately the next time they bring the app to the foreground.

Offline, the app keeps the last set it knew about. A refresh that fails changes nothing, so a user with no connection carries on with the access they had — which is worth remembering when revoking access from someone who is out in the field.

What a blocked user actually sees

Nothing. A control the user lacks permission for is removed from the screen, not greyed out and not left to fail on tap. There is no error to report and no hint that something is missing.

This is why “the button has disappeared” is the usual symptom of a permission problem, and why it is easily mistaken for a bug.

The exception is a plan shortfall, which renders as a visible locked item with an upgrade prompt — because there the point is to tell you the feature exists.

Platform operator accounts bypass all three axes.

Related

• Accounts, companies and locations
• Plans and what they unlock
• Working offline