Roles & permissions

Every staff user has exactly one Role (/roles/, needs roles.manage), and a role is just a named set of permissions. RedScribe ships four built-in roles with sensible defaults, but roles themselves are fully dynamic. You can edit the built-in ones or create entirely new ones with any combination of permissions.

Built-in roles

Role	Default permissions
Superadmin	Every permission, always. Not editable, and always requires MFA regardless of the instance-wide mfa_required toggle.
Team Lead	engagements.create, engagements.manage, engagements.view_all, engagements.release_to_client, catalogue.manage, catalogue.approve, catalogue.delete_any, findings.review, findings.review_own, findings.qa, findings.qa_own, reports.trends, checklist_templates.manage, clients.manage
Senior	findings.review, findings.qa, catalogue.approve
Consultant	(none by default; engagement membership is what grants day-to-day access)

These defaults are a starting point, not a fixed hierarchy. Edit any non-Superadmin role’s permission set from its detail page.

Every permission

Permission	What it grants	Category
engagements.create	Create engagements	Engagements
engagements.manage	Manage engagement membership, metadata, and scope-change approval (non-archived engagements)	Engagements
engagements.view_all	View every non-archived engagement without needing explicit membership	Engagements
engagements.release_to_client	Approve releasing an engagement’s findings to the client portal	Engagements
catalogue.manage	Create, edit, and delete vulnerability catalogue templates	Catalogue
catalogue.approve	Approve draft vulnerability catalogue entries	Catalogue
catalogue.delete_any	Delete any catalogue entry, including ones created by someone else	Catalogue
catalogue.bulk_manage	Export/import the whole vulnerability catalogue at once	Catalogue
checklist_templates.manage	Manage checklist templates	Checklist
report_settings.manage	Manage report profiles and export settings	Reports
reports.trends	View cross-engagement trend reporting	Reports
findings.review	Review findings (eligible to be assigned as reviewer)	Finding Review
findings.review_own	Review findings authored by yourself	Finding Review
findings.qa	QA findings (eligible to be assigned as QA reviewer)	Finding Review
findings.qa_own	QA findings authored by yourself	Finding Review
findings.act_any_assignment	Submit any finding’s review/QA decision, regardless of who it’s assigned to	Finding Review
clients.manage	Manage client-portal companies and accounts	Client Portal
users.manage	⚠️ Manage user accounts (create, deactivate, change roles)	Administration
roles.manage	⚠️ Manage roles and permissions, including this list	Administration
feature_flags.manage	Manage feature flags	Administration
licensing.manage	Manage the license key	Administration
audit_log.manage	View and purge the audit log	Administration
field_visibility.manage	Manage which finding/catalogue fields are visible	Administration
branding.manage	Manage firm branding (name, logo) shown on the login page, sidebar, and reports	Administration

See Permissions reference for this same table in a form meant for quick lookup while configuring a role.

users.manage and roles.manage are effectively Superadmin-equivalent

Someone holding users.manage can change their own role, including to one that holds roles.manage. Someone holding roles.manage can grant themselves (or anyone) every permission in this list. Only grant either of these to someone you’d trust with full Superadmin access anyway. There is no technical barrier between “can manage users/roles” and “is Superadmin,” only how far they choose to take it.

findings.review_own / findings.qa_own vs. findings.act_any_assignment

These solve different problems:

• *_own lets someone review/QA findings they wrote themselves, which is useful for a small team where strict segregation of duties on every single finding isn’t practical.
• findings.act_any_assignment lets someone act on any finding’s review/QA decision regardless of who it’s assigned to, which helps a Team Lead cover for an absent reviewer without having to reassign the finding first just to unblock it.

Neither implies the other; grant whichever matches the actual workflow gap you’re solving.