> For the complete documentation index, see [llms.txt](https://docs.startdeliver.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.startdeliver.io/platform-settings/permissions.md).

# 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.