Built-in roles explained

Suprata ships with a small set of seed roles meant to cover common service-business shapes. Here's what each one is for, the permissions it grants, and when it's the right pick.

Updated 12 hours ago 5 views users roles permissions concepts

Built-in roles explained

When you create a new staff user in Suprata, you have to assign them a role. The system ships with a handful of seed roles that cover most of what a service business needs out of the box. They're a starting point — you can use them as-is, edit them, or build your own.

This article walks through what each built-in role is meant for, the permissions it typically grants, and when to use it. The exact list and naming in your account may differ from these defaults if your administrator has customized things.

Where roles live

Sidebar: Team Settings → User Roles.

The Manage Roles screen — each role shows its granted permission chips

Each row is a role. The right column shows the permissions that role grants, rendered as colored chips. Click any role to drill into its full permission list and edit.

The "+ Add Role" button creates a new role. Almost always start by cloning an existing role rather than building from scratch — see When to create a custom role for the right pattern.

The typical seed roles

Your account starts with these roles (or close variants — names sometimes vary):

Super Administrator

The "owner" role. Has every permission in the system, including:

  • Edit Company Settings.
  • Add, edit, delete users.
  • Assign roles (the only role that can change who has admin access).
  • Edit invoices, payments, refunds.
  • Configure integrations (QuickBooks, Stripe, etc.).
  • Run any report.
  • Edit any record.

Use for: the business owner, the office manager, the administrator. Typically 1-3 users in a typical small business.

Don't use for: anyone whose job doesn't require global access. Super Admin is over-permissioned for most non-owner roles.

A specific danger: Super Admin can delete other users. If you have multiple Super Admins, any one of them can lock the others out. Trust matters.

Administrator

Like Super Admin but typically cannot assign roles. Otherwise has the run of the system.

Use for: office managers, lead dispatchers, anyone who needs broad system access without the ability to grant other people admin powers.

The distinction between Super Admin and Administrator is "can this person promote other people to admin?". The answer should be "no" for most administrative-style users.

Technician

Field-tech role. Limited to what a tech actually needs:

  • See their own assigned jobs (often filtered by user assignment).
  • Update job status (Scheduled → In Progress → Complete).
  • Add notes and photos to jobs.
  • Capture customer signatures.
  • Log time against jobs.
  • Use the time clock.
  • Sometimes: see and edit the customer's contact info.

Typically does not have:

  • Access to invoicing details (price, profit, margin).
  • Access to other techs' jobs.
  • Settings access.
  • Reports (or only personal performance reports).

Use for: the people doing the actual work in the field.

Don't use for: lead techs who also dispatch — they need broader scheduling permissions. Make a "Lead Tech" custom role for that.

Dispatch / Scheduling

Operations role. Can:

  • See the full dispatch board and calendar.
  • Create, schedule, and reassign jobs.
  • Move appointments around.
  • See all techs' schedules.
  • Communicate with customers (call, SMS, email).
  • See basic customer info.

Typically does not have:

  • Pricing or invoice editing.
  • Ability to issue refunds.
  • Settings or user management.

Use for: dispatchers, schedulers, the operational hub of the business.

Accounts Receivable / Billing

Money role. Can:

  • Create, edit, send invoices.
  • Apply payments and credits.
  • Issue refunds.
  • Run revenue, A/R, and tax reports.
  • See customer payment history.
  • Sync to QuickBooks (if relevant).

Typically does not have:

  • Job creation or scheduling (read-only).
  • Settings or user management.

Use for: the office person who handles billing, your accountant or bookkeeper if they have direct access.

Read-Only / View Only

A view role with no edit permissions anywhere. Can see jobs, invoices, customer history, reports — but can't change anything.

Use for:

  • Auditors or external accountants doing point-in-time review.
  • Trainees during their first week before they're given write access.
  • A senior manager who wants visibility but doesn't operate the system.

Payroll

Time-and-attendance role. Can:

  • See and edit time-clock entries.
  • Run payroll and time reports.
  • Adjust time entries with audit trail.

Typically does not have:

  • Job, invoice, or customer access (or only read access).

Use for: your bookkeeper or payroll person if they handle pay periods inside Suprata.

How to think about the role spectrum

Imagine your staff on an axis from "low trust" to "high trust" and from "narrow scope" to "broad scope":

            Narrow scope ←—————→ Broad scope

High trust:   Tech              Super Admin
                                   Admin
                                Dispatch

Lower trust:  Read-Only         (rare; build a custom role)

The seed roles cover the corners well. Custom roles fill in the middle as your team grows and specializes.

When the seed roles cover everything

If you have:

  • A small team (under 8 staff).
  • Clear job functions (techs, dispatcher, owner, bookkeeper).
  • No special compliance requirements.

The seed roles are probably enough. Don't over-engineer permissions early — you'll know when you need more.

When you'll outgrow the seed roles

Three common signals it's time for custom roles:

  • You have a "lead tech" or "shop foreman" role — more than a tech but less than a dispatcher. Cloning Tech and adding a few permissions is the right move.
  • You have a sales role — quotes and estimates but no actual job execution. Clone Dispatch, remove a few things, add estimate permissions.
  • You have an external bookkeeper who shouldn't see operational data. Clone Accounts Receivable, narrow scope to billing-only, give them their own login.

See When to create a custom role for the pattern.

Common mistakes

  • Making everyone Super Admin. Tempting because permission errors go away. Also gives every staff member the ability to delete other users and see payroll. Don't.
  • Treating role names as immutable. Your account's "Technician" role can be renamed and re-permissioned. The name is just a label; the permissions are what matters.
  • Building per-person roles. "Mike's permissions" works for a team of three, breaks at twelve. Build roles for job functions, not individuals.
  • Forgetting that role changes affect existing users. Removing a permission from "Technician" affects every user assigned to that role, not just future hires. Plan changes carefully.
  • Not auditing roles periodically. Once a year, walk through the role list with someone outside the day-to-day operations. "Should the Tech role really have access to delete customer notes?" — questions like that surface things that drifted.

Related articles