Skip to content

Role Model

Primary role matrix

Role or mode Why it exists Typical responsibility Important boundary
user normal tenant operations read and work in assigned monitoring scope no broad admin rights
manager broader operational maintenance without full admin ownership write access to operational areas still not a platform role
admin company-level administration users, tags, groups, notifications, jobs, storage, metrics in company scope not platform-global
superadmin platform governance and operations companies, cross-company users, metrics, worker tuning, global docs access strongest scope, should be deliberate
systemadmin group technical system-docs and operating access system-facing documentation and operations narrower concept than full superadmin in some flows

Frontend-visible role logic

Current frontend helpers include:

  • isAdmin
  • isSuperAdmin
  • canAccessSystemDocs
  • isSuperAdminGlobalScope
  • isSuperAdminCompanyScope
  • isManager
  • isMember
  • canWrite
  • hasTagScope
  • hasFocusedScope

UI impact matrix

Role or mode UI effect
user standard tenant and monitoring routes
manager write-oriented product behavior through canWrite
admin /admin/* becomes relevant
superadmin global /superadmin/*, global company switching, system docs access
superadmin company superadmin identity with narrower effective company scope
focused scope /focused/* routes and narrower tenant experience

Why focused scope exists

Focused scope exists to reduce overload and tighten visibility for people who should work on a smaller tenant subset or tag-limited operational area.

Role boundaries in practice

  • role decides broad functional responsibility
  • company scope decides which company data is in play
  • tag scope decides which tenant or flow subset is visible
  • resource restrictions decide whether payloads or custom headers stay readable

For the enforcement layer, continue with Permission Model.