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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.startdeliver.io/platform-settings/permissions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.