Who Can See and Change What

This is the question we get asked most, so it's worth getting straight up front. Aptli's access model is deliberately simple, and it starts from one default:

By default, everyone can see everything — but not everyone can change everything. Visibility is open out of the box; the ability to edit is what you grant. You then narrow visibility only where you specifically need to.

Control happens in two independent layers. They stack: a person's final access to any record is whatever both layers allow.

   START: everyone can SEE everything
              │
              ▼
   ┌──────────────────────────────────────────────┐
   │ LAYER 1 — ADMIN RIGHTS                        │
   │ "What may this person CHANGE?"                │
   │ Granted per area, per action.                 │
   │ No right → can view, but not create/edit/delete
   └──────────────────────────────────────────────┘
              │
              ▼
   ┌──────────────────────────────────────────────┐
   │ LAYER 2 — ROLE RESTRICTIONS                   │
   │ "What may this person's role even SEE?"       │
   │ Hides matching records from the role —        │
   │ everywhere those records would appear.        │
   └──────────────────────────────────────────────┘
              │
              ▼
   RESULT: what this person can see and do

Layer 1 — Admin rights (what you can change)

Every person carries a set of admin rights. Each right is a single switch for one action in one area — for example jobsUpdate, sitesDelete, resourcesCreate. Hold the right and you can perform that action; don't hold it and you can't.

The pattern is consistent across the whole system: most areas have a create, an update, and a delete right.

   Jobs        →  jobsCreate · jobsUpdate · jobsDelete
   Sites       →  sitesCreate · sitesUpdate · sitesDelete
   Resources   →  resourcesCreate · resourcesUpdate · resourcesDelete
   Reports     →  reportsCreate · reportsUpdate · reportsDelete
   ... and so on for every area

With no rights, a person is effectively read-only: they can open and view records across the app, but the create/edit/delete controls aren't available to them. You hand out rights to widen what each person is allowed to do.

A handful of rights aren't about a single area — they unlock a capability, such as View Deleted (viewDeleted), Facilitate Pickups, or Audit View. These work the same way: held or not held.

Layer 2 — Role restrictions (what you can see)

The first layer never hides anything — it only governs editing. To take content out of view, you use roles.

A role is a named group of people that carries a list of restrictions. Each restriction is a rule that says, in effect: "members of this role should not touch records that match this condition." The primary thing a restriction does is hide matching records — they simply don't appear for that role, anywhere.

The three tiers

For any given record, a person ends up in exactly one of these:

   ┌────────────────────────────────┬──────┬───────┐
   │                                │ SEE  │ EDIT  │
   ├────────────────────────────────┼──────┼───────┤
   │ Open                           │  ✓   │  ✓ *  │
   │ View-only                      │  ✓   │  ✗    │
   │ Hidden          (role-hidden)  │  ✗   │  ✗    │
   └────────────────────────────────┴──────┴───────┘

   * Editing requires the matching admin right from Layer 1.

Open — visible, and editable by anyone who holds the relevant admin right.
View-only — visible, but not editable. This is simply what you get for any record where a person doesn't hold the edit right (Layer 1). Since visibility is open by default and editing is granted, most people are view-only on most things — that's the normal state, not a special lockdown.
Hidden — a role hides the record, so it isn't in that person's lists or on their map at all.

Because role rules attach to records that match a condition (not to whole pages), one role can see a subset of jobs, sites, or features while another role sees a different subset of the same collection.

It works at every level

Hiding via roles isn't a feature of one screen. The same view rules apply uniformly across the system — jobs, work orders, reports, resources, sites, stock, map features, users, roles, and more all run their lists through the current person's role restrictions. Hide a category of records for a role in one place and it's hidden everywhere that role looks.

A note on the two layers working together.Hiding is driven by roles and applies everywhere. Editing is driven by admin rights — so the reliable way to make something read-only for a group is to withhold its edit right. (Roles can also carry edit/create/delete rules, but treat the admin right as the real edit gate.)

The exceptions to "everyone can see everything"

The open default has a few deliberate carve-outs:

Deleted records are hidden unless a person holds the View Deleted right and asks to show them. Soft-deleted items stay recoverable but stay out of the way.
Personal sites belong to their owner. A worker's personal inventory site is visible to others, but only its owner can edit it — regardless of site rights.
Orphaned map features (whose parent layer was deleted) stay hidden unless you're explicitly viewing deleted content.

Everything else follows the rule: open to see, granted to change, narrowed by role where you decide it matters.

How this maps to the admin area

You manage both layers from the Admin menu:

Users — assign a person's admin rights (Layer 1) and their role membership.
Roles — define roles and their restrictions (Layer 2).
Granting Access — bring new people in and set them up.

For the full security picture, see Authentication (how people prove who they are) and Authorization (how rights and roles are configured in depth).