Access Presets

Until now an access level was all-or-nothing: an Admin got every Admin permission, or you didn't make them an Admin. Access presets let you define a curated subset of a role once, name it, and assign it to people — so you can give someone exactly the access they need without inventing a new role.

A common example: a "Site Supervisor" who should do everything a Manager does except touch payroll. Instead of granting the full Manager role, you build a Manager-based preset that leaves payroll out, and assign that.

Where to find them

• Create and manage presets: Settings → Access Presets.
• Assign a preset to someone: Users → click a member → apply one from their access editor.

The three layers of access

Access is decided in three layers, and it only ever narrows as you go down — never widens:

1. Access Level (the role) — the hard ceiling. This is the system role: Owner, Admin, Manager, or Field (plus the Customer and Supplier portal roles). Nothing below can exceed it.
2. Access Preset — an account-defined, named subset of a role. A preset can only remove permissions from its base role, never add.
3. Per-member tweaks — after applying a preset you can trim a single person's access further. You can only remove more; anything outside the role, or already removed by the preset, is greyed out.

The access level is the ceiling

A preset can only ever take permissions away from its base role — it can never grant something the role doesn't already have. A preset built on Manager can never do anything a Manager couldn't.

This is enforced in the database, not just in the interface, so the ceiling holds everywhere the permission is checked — including the API and integrations, not only the screens.

The same rule one level down

After a preset is applied you can fine-tune access for that one person. The same principle applies: you can only narrow further. Any permission that is outside the role, or has already been removed by the preset, is greyed out and can't be turned back on here.

So access flows in one direction only:

Access Level → Preset → Per-member tweaks — each step can remove, none can add.

Permissions know their dependencies

Permissions aren't independent switches — some depend on others, and the editor keeps them consistent for you:

• Turning on Update Quotes automatically enables View Quotes (you can't update what you can't see).
• Turning View Quotes off removes everything that depends on it.

Like the ceiling, these dependency rules are enforced in the database, so a preset or override can never end up in an inconsistent state.

Quick picks are starting templates

When you create a preset you can start from a quick pick instead of a blank slate:

• Site Supervisor
• Payroll Officer
• Estimator

Picking a template also sets the base role for you — choose the template first, then adjust. More generally, changing the base role mid-edit resets the checklist to that role's full ceiling rather than carrying your previous edits over, so you always start from a clean, valid set for the new role.

Base roles you can build on

Presets can be built on Admin or Manager.

• Owner is deliberately excluded — an Admin building a preset shouldn't be able to narrow (and therefore act on) an Owner.
• Field and the portal roles (Customer, Supplier) are already minimal, so there's nothing to curate.

Edits are live

Change a preset and everyone assigned to it updates immediately — there's no need to re-assign it to each person.

Deleting a preset widens access

Because a preset only ever restricts, deleting one widens access: anyone who was on it falls back to their full access level. To make that impossible to miss, the delete dialog tells you how many people it affects before you can confirm.

You can't lock yourself out

Applying a preset to yourself that would remove your own ability to manage roles is blocked — so you can't accidentally cut off your own access to the permissions screen.

Per-organisation

Presets are defined per account. Each organisation builds its own; nothing is shared or global across accounts.

Everything is audited

Preset changes and per-member assignments are all journaled, so there's a record of who changed access and when.

What this replaced

Earlier versions of Assignar Pay included a separate Member role for basic access. That role has been retired in favour of this layered model: former members now sit on the Manager role, and where they previously had a narrower-than-Manager set, that exact set is preserved as a "Member (migrated)" preset. Their effective access is unchanged — see Understanding Roles and Permissions for the current list of roles.