Roles & Permissions

Overview

Every user in Straightline has a User Type that determines what they can see and do. Straightline ships with three built-in user types, and administrators can create additional custom roles with fine-grained permission control.

Built-in User Types

Straightline provides three standard user types that cover the most common access patterns:

User Type	Access Level	Tenant Settings
Super Admin	Full access to everything, bypasses usage limits	Full read & write
Tenant Admin	Full access to all features	Full read & write
General User	Full access to all features	Read-only

Super Admin

Super Admins have unrestricted access across all modules and settings. They can bypass subscription usage limits and have access to all additional features. Typically assigned to the account owner or primary administrator.

Tenant Admin

Tenant Admins have full access to all CRM features and can manage Organization Settings (roles, team, billing, email, audit trail, support). They cannot bypass usage limits — those still apply. This is the recommended role for department managers and team leads who need to configure the account.

General User

General Users have full access to all CRM features — Leads, Contacts, Deals, Automations, Integrations, and Traffic. However, their access to Organization Settings is read-only: they can view roles, team members, billing, and other settings but cannot make changes.

This is the right choice for most team members who need to work in the CRM but should not be able to change account configuration.

Custom Roles

In addition to the built-in types, administrators can create custom roles with specific module-level permissions.

Understanding Permissions

Each module has its own permission set. For example, the Leads module has permissions like "Can view lead", "Can add lead", "Can delete lead", and "Can list all leads". A custom role can include any combination of these across all modules.

List All vs List Own

Many modules have two list permissions — List All and List Own:

List All — the user sees every record in the organization.
List Own — the user sees only records they created or were assigned to.

Assign "List Own" to roles that should have limited visibility into the full pipeline.

Creating a Custom Role

Go to Organization Settings → Roles.
Click Create Role.
Enter a name that describes the role's responsibility.
Toggle the permissions you want for each module.
Optionally enable:
Full Access — grants all permissions across all modules (equivalent to Tenant Admin for regular features)
Tenant Settings Access — grants full read/write access to Organization Settings
Read-Only Settings — grants read-only access to Organization Settings (same as General User behavior)
Save. The role is immediately available to assign to team members.

Editing a Custom Role

Click the role name to open it. Toggle permissions on or off and save. Changes apply immediately to all users assigned to this role — no need to update individual users.

Deleting a Custom Role

A custom role can only be deleted if no users are currently assigned to it. Reassign those users to another role first, then delete.

Read-Only Settings Access

The Read-Only Settings flag is what General Users have by default. When enabled on any role:

The user can navigate to Organization Settings and view all pages.
They cannot create, edit, or delete anything in Organization Settings.
All forms and action buttons are inaccessible (POST requests are blocked server-side).

This is useful when you want team members to see the current configuration — for example, viewing billing limits or reading role definitions — without being able to change anything.

Tips

Use the three built-in user types for the vast majority of your team. Custom roles are for specialized access patterns.
The General User type is ideal for most team members — full CRM access with read-only visibility into settings.
Assign Tenant Admin only to people who genuinely need to change organization configuration.
Periodically review who has Tenant Admin or Super Admin access and reduce it where not needed.
When in doubt, start with a more restrictive role. It is easier to grant more access later than to explain an overpermission.