Permissions

Settings → Permissions · Requires Admin access to configure

Configure who on your team can see and do what in Startdeliver. Permissions are built around Team Member types - roles you assign to each team member that control exactly what customers, data, and settings they can access.

How it works

There are two components:

• Team Member types — the roles themselves, each with their own permission configuration. You assign a type when inviting or editing a team member.

• Permission rules — reusable rule sets you build once and apply to any number of types. Useful when multiple types should share a specific permission configuration.

Team Member types

Default types

Three types come built in and cover most CS team structures.

Type	Who it's for
Admin	CS managers, operations leads, anyone who configures the platform. Full account access.
Main	Standard CSMs. The default for any team member who isn't an admin.
Lite	Observers, stakeholders, or junior team members who need visibility with limited ability to make changes.

Default types cannot be deleted, but their permissions can be fully customised.

Custom types

Create a custom type when the defaults don't match your team structure. Common examples: Team Lead (full access to their team's portfolio), Revenue Operations (read-only across all accounts), or Specialist (write access to specific objects only).

Go to Settings → Permissions and click + Add a custom Team Member type.

Partner types

For external collaborators — resellers, integration partners, agency partners. The built-in External Partner type is available by default. Partner types follow the same permission model but are kept separate from internal types.

Click + Add a partner Team Member type to create additional partner types.

Permission categories

Each Team Member type is configured across the following categories:

Customers and their related objects

The most important category. Controls access to customer records and all objects attached to them — Users, Projects, Tasks, Files, and Comments.

This category has two sub-sections:

• Permissions for customer items — the 4 core actions (Read, Write, Create, Delete) on the customer record itself, plus field visibility controls

• Permissions for related items — actions on all related items except customers

You can also add child entities to configure individual object types separately — for example giving a type different permissions on Tasks vs Files vs Comments. See the full entity list below.

Team members, Teams, Permissions, and other access

Controls whether a member can manage people and roles. Contains three specific controls:

Control	What it does
Grant admin	Whether this type can grant admin rights to others
Team Member type permissions	Whether they can create or use Team Member types
Invite	Whether they can invite new team members

Settings access

Controls access to personal, team, and account-level settings.

Advanced settings access

Fine-grained control over specific account configuration keys. Use this to lock down sensitive platform settings for non-admin types.

Route access

Controls access to non-entity routes such as file upload, download, and connected apps. Available on Main and custom types.

Permissions for general objects

Controls access to non-customer objects — shared templates, global playbooks and other account-wide resources.

Use this when you need to give a team member access to one specific resource without opening up the entire category. For example, give a partner access to a single project template without granting access to all templates.

To whitelist specific objects: open the permission settings for the relevant type → find the object category → select the objects you want to allow.

Permission levels

For customer-related categories, each action (Read, Write, Create, Delete) can be set to one of six levels:

Level	What it means
Same as default	Inherits the account-wide default. Start here and only override where needed.
Assigned customer	Allowed only on customers this team member is personally assigned to
Team's assigned customers	Allowed on customers assigned to this team member or anyone on their team
Created customer	Allowed only on customers this team member created
Team's created customer	Allowed on customers created by this team member or anyone on their team
None	Never allowed, regardless of assignment or team

For non-customer categories (Team members, Settings, Route access), permissions use simpler Has Access / No Access controls with specific sub-options per action.

Field visibility

Within customer permissions, you can control which fields are visible to a type. Two modes:

• All visible (default) — all fields are shown. Select individual fields to hide.

• All hidden — all fields are hidden. Select specific fields to show.

Use this when different roles need different views of a customer record. For example, a Lite user might not need to see ARR, internal notes, or health score details.

To configure: open the permission settings for a type → Customers and their related objects → expand Permissions for customer items → scroll to Field visibility.

Use + Add field override to apply visibility rules to individual fields under specific conditions.

Child entities

Within the Customers category, you can configure permissions for specific related objects separately from the default. Click Add child entity and select from the dropdown.

Permission rules

Permission rules are reusable configurations you build once and apply to multiple types. Instead of manually setting the same scope on several types, create a rule and reference it wherever needed.

To create: Settings → Permissions → + Add a custom Permission under the Permission rules section.

How to create a new Team Member type

1. Go to Settings → Permissions

2. Click + Add a custom Team Member type

3. Give it a name and description

4. Click into each permission category and configure the scope for each action

5. Optionally configure field visibility for customer records

6. Click Save — the type is now available when inviting or editing team members

How to assign a type to a team member

1. Go to Settings → Team

2. Find the team member and click to edit

3. Select their type from the dropdown

4. Save

You can also set the type when inviting a new team member.

Common setups

Standard CSM team

Use the Main type. Set Write and Delete to "Assigned customer" so CSMs can only edit their own accounts. Keep Read as "Same as default" so they have full portfolio visibility for context.

Team lead with full team access

Create a custom type. Set all actions to "Team's assigned customers". The lead can read and edit any account their direct reports are assigned to.

Read-only stakeholder

Use Lite, or create a custom type with Read set to "Same as default" and Write, Create, Delete all set to "None".

External partner with limited field access

Use a Partner type. Set Delete and Create to "None". Use Field visibility in "All hidden" mode and expose only the fields relevant to the partner relationship.

Locked-down junior CSM

Set Read to "Assigned customer" across the board. They only see what they're directly assigned to — no portfolio-wide visibility.

Hiding sensitive fields from a type

Use "All visible" mode and add the fields you want to hide under Field visibility. ARR, health scores, and internal notes are common candidates for field-level restrictions.