Skip to main content
iWorkWhen uses role-based access control with granular permissions. Every sensitive action in the app maps to a single permission key (e.g. trades.approve). Roles are named collections of permissions. Users have one or more roles — their effective permissions are the union of their roles’ permissions.

​
How it flows

1

Admin defines roles

Roles bundle permissions. Out of the box: Admin, Supervisor, Lead, Dispatcher, Trainee. Admin can edit non-system roles or create new ones.
2

Admin assigns roles to users

When creating or editing a user, pick the boxes for each role that applies. A user can have multiple roles.
3

App enforces permissions everywhere

  • Server actions check hasPermission() before running.
  • Pages redirect unauthorized users to a forbidden screen.
  • Database has Row Level Security (RLS) policies that cross-check permissions inside Postgres — so even a compromised client can’t bypass the rules.

​
Categories

Permissions are grouped by category:
CategoryWhat it covers
selfActions on your own data — view your schedule, request your own PTO, trade your shift
adminUser and org management — create users, manage roles/groups/locations/rules
scheduleBuilding and publishing schedules, managing shift patterns/coverage/duties
approvalApproving others’ trades, absences, overtime
biddingRunning bidding rounds and submitting bids
reportsViewing and saving reports
saSpecial assignments (categories + assignments)

​
Default roles

Has all permissions, including the ability to edit roles and manage SMTP. Flagged as a system role and can’t be deleted.
All self-permissions, plus: view users/groups/locations, view all schedules, publish schedules, manage shift patterns/coverage/duties, approve trades/absences/overtime, record trades and absences, view reports, manage special assignments.Cannot manage users, roles, SMTP, or customer rules.
All self-permissions, plus: view users, view all schedules, view shifts/coverage/duties, approve trades and absences (not overtime).
Standard employee: view own schedule, edit own profile, create trade and absence requests, volunteer for overtime, create notes, send messages, bid on vacation and shifts, view special assignments.
Limited: view own schedule, edit own profile, create notes, send messages, view special assignments. No trade/PTO/OT — trainers do those on their behalf.

​
Designing your own roles

You’re not stuck with the defaults. Common additions:
  • Trainer — Dispatcher + sa.manage (so they can assign training blocks).
  • Scheduler — shifts.manage + shift_patterns.manage + schedule.publish + coverage.manage but nothing else. Builds schedules but can’t approve trades.
  • HR — timebank.view.all + absences.approve + users.manage but not schedule-related.
When you change a role’s permission set, it takes effect on the user’s next page request. There’s a short-lived in-memory cache (a few seconds) that flushes automatically.

​
Audit

Every change to users, roles, permissions, SMTP settings, and customer rules is written to the audit log. Only users with users.manage can read it. → See Audit log and the full Permissions reference.