When to create a custom role (and when not)

Custom roles are one of the most-overused features in business software. The temptation: someone has slightly different needs, so make them a custom role. The result, six months in: a role catalog with 24 entries that nobody can remember the difference between, half of them used by exactly one person.

This article covers the three signals that do warrant a custom role, the signals that don't, and the cloning pattern that keeps the role catalog from sprawling.

The three signals that warrant a custom role

Signal 1: a coherent job function that doesn't fit any existing role

You have at least two people (now or planned) who share the same job function, and no built-in role matches that function within ~80%.

Examples:

Lead Tech / Shop Foreman. Does field work like a Tech, but also schedules other techs and reviews their work. Built-in Tech is too narrow; built-in Dispatch is too broad.
Sales Rep. Quotes and estimates, doesn't execute work. Needs to see customer history and create estimates, but not invoices or job assignments.
Estimator. Creates estimates from on-site visits. Like a Tech but with permission to bind pricing.
Customer Service Rep. Handles calls and emails, can update customer records, can see jobs but not change them.

If "at least two people would use this role and no built-in role gets us 80% of the way there", you have a real custom role.

Signal 2: a compliance or audit requirement

Sometimes external policy demands a role that doesn't naturally exist:

Read-Only Auditor with access to historical records but not present-day operational data.
PCI-Restricted Office Person who handles general support but explicitly cannot see saved card data or initiate refunds.
HIPAA-Restricted Field Tech (for service businesses in healthcare contexts) with redacted access to patient-related notes.

These are real and warrant custom roles. The compliance case is strong because "the role should match the policy" is a clear, defensible boundary.

Signal 3: significant scope mismatch with built-in roles

You have a person whose responsibilities are narrower than any built-in role they'd otherwise be assigned to.

Example: an external bookkeeper who needs to see invoices and payments to do their work but should not see customer addresses or job notes (privacy boundary). Built-in Accounts Receivable is right function-wise but too broad on data access.

The custom role here is "Bookkeeper-External", cloned from Accounts Receivable with customer-detail permissions stripped out.

The signals that do NOT warrant a custom role

Don't: "this one person has a slightly different need"

If exactly one person needs slightly different permissions, don't make a role for them. The pragmatic move is to use the closest existing role and accept some over- or under-permissioning — most permission decisions don't matter for any one specific person, and a role spun up for an audience of one becomes a maintenance liability the moment that person changes jobs or leaves.

If the gap is real and the closest role is genuinely wrong, that's a signal more people are coming who need the same thing — wait until you have two or three of them, then design the role around the pattern.

Don't: "this is the way I've always organized roles in other systems"

The software you used before had its own way of doing roles. Don't try to recreate it here without thinking. Suprata's roles work the way Suprata works — start with the built-in roles and let real-world problems drive any changes.

Don't: "I want to be cautious"

Building 12 custom roles with subtle differences "to be safe" creates more risk than it removes. People get assigned the wrong role, permissions drift, audits become harder. Default to simplicity.

Don't: a role for every tier or seniority level

"Tech Level 1", "Tech Level 2", "Tech Level 3" — three roles that probably do the same thing in software but represent pay-band differences in HR. Don't model HR distinctions in the role system. Use one Tech role for all field techs and let HR handle the rest in payroll.

The cloning pattern

When you do create a custom role, always clone an existing role rather than building from scratch.

Why: you'll forget to grant permissions you meant to. You'll grant permissions you didn't mean to. The seed roles have been thought through; they're the safest baseline.

The flow:

Open Team Settings → User Roles.
Find the role closest to what you need.
Click into it; look for a "Clone" or "Duplicate" action (or copy the permission list manually if cloning isn't directly supported).
Rename the new role for the job function, not the person.
Adjust the permission set — typically you'll remove a few and add one or two.
Test: create a test user with this role; click around as that user; verify they can do what they should and can't do what they shouldn't.

Naming roles well

Role names outlive the people they describe. A few principles:

Name by job function, not by person. "Lead Tech", not "Mike's permissions".
Use verbs for what the role does, not nouns for who they are. "Estimator" beats "Sales Side".
Match the language your business uses internally. If your team calls field techs "fitters", use Fitter, not Tech.
Avoid "Junior" / "Senior" unless the permission set actually differs.
Don't include team/branch identifiers in role names. "Houston Office Tech" is wrong — that's a Team or Business Unit, not a role.

Permission audits

Set a calendar reminder once a quarter to walk through your role list with someone who isn't deeply in the day-to-day. Questions to ask for each role:

Is this role still in use? If nobody's assigned to it, archive it.
Does it grant permissions someone in this role doesn't actually need? Remove them.
Is there a permission this role should have but doesn't (per recent friction)? Add it.
Are there roles that have drifted toward each other and could be merged?

A 20-minute quarterly audit prevents the role list from sprawling.

Worked example: making a "Lead Tech" role

You have three field techs. One of them (Mike) is the senior, and you want him to be able to:

Do everything a regular tech does (so start from the Tech role).
Schedule his own crew's work for the next day.
See and adjust the other two techs' jobs (when he's filling in for a dispatcher).
See basic invoice info on jobs (so he knows what was billed).
Approve other techs' time entries before they go to payroll.

Two more people are about to be promoted to lead-tech status, so this is a real recurring role, not a Mike-special.