> For the complete documentation index, see [llms.txt](https://docs.birdie.so/birdie-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.birdie.so/birdie-docs/helpdesk/salesforce-service-cloud/permissions.md).

# Permissions

***

### Setting up the integration user

There are two ways to grant the Birdie integration user its access. **We recommend the permission set** - it's a single step and updates automatically with each Birdie release.

{% hint style="success" %}
**Recommended: assign the “Birdie Integration User” permission set.** Birdie ships a managed permission set that grants the integration user everything it needs (with the two exceptions noted below). Because it's part of the package, future permission changes arrive automatically with your next Birdie upgrade - no manual edits required.
{% endhint %}

#### Option 1 - Assign the managed permission set (recommended)

**Prerequisites:** you're on Birdie package **v1.22 or later**, and you have a dedicated integration user (ideally on a **Minimum Access – Salesforce** profile).

1. Go to **Setup → Permission Sets**.
2. Open **Birdie Integration User**.
3. Click **Manage Assignments → Add Assignment**.
4. Select your Birdie integration user, then click **Assign**.

Or with the Salesforce CLI:

```bash
sf org assign permset -n sfbirdiecx__Birdie_Integration_User -o <your-org-alias>
```

**Two things a permission set can't carry** - handle these separately if they apply to you:

* **Salesforce Messaging** - only if you capture recordings through Messaging sessions. Additionally grant Read on **MessagingSession** and permission to send via the `sendConversationMessages` action (see the Messaging section below).
* **Connected App OAuth scopes** - these live on the Birdie connected app you authorize during installation, not on the user, so there's nothing extra to configure here.

#### Option 2 - Configure the permissions manually

Prefer to build the access by hand, or want to see exactly what's granted? The complete breakdown follows.

***

### System permission

* **API Enabled**
* **View All Users** - the lever for reading your agent list (User has no per-field FLS to grant)

### Object permissions + field-level security

| Object                                                            | Access       | Fields                                                                                                                                                                                                       |
| ----------------------------------------------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Case**                                                          | Read, Create | `Subject`, `Description`, `Origin`                                                                                                                                                                           |
| **Contact**                                                       | Read         | `Email`                                                                                                                                                                                                      |
| **Account** *(optional)*                                          | Read         | `<Any_Routing>__c` (storage-routing field, if configured)                                                                                                                                                    |
| **Email Message** (`EmailMessage`)                                | Read, Create | `ParentId`, `FromName`, `FromAddress`, `ToAddress`, `Subject`, `TextBody`, `HtmlBody`, `MessageDate`, `Status`, `Incoming`                                                                                   |
| **Messaging Session** (`MessagingSession`) *(Messaging only)*     | Read         | `Id`, `CaseId`, `Status`, `MessagingEndUserId`                                                                                                                                                               |
| **Birdie Recording** (`sfbirdiecx__Birdie_Recording__c`, managed) | Read, Edit   | `FirstViewedAt__c`, `LastViewedAt__c`, `AnonymousViewCount__c`, `FirstAnonymousViewedAt__c`, `LastAnonymousViewedAt__c`, `BirdieAuthViewCount__c`, `FirstBirdieAuthViewedAt__c`, `LastBirdieAuthViewedAt__c` |

{% hint style="info" %}
**Accessed by Birdie, but nothing to grant here.** Birdie also touches the items below - you don't (and in most cases can't) grant them individually; they're covered by the access above:

* **`Case.Id`** and other system fields - always accessible; no FLS exists to grant.
* **Case Comments** (`CaseComment`) - where Birdie posts recording links. Governed by **Case** access (Read + Create above), not a separate object permission - it won't appear in the object list.
* **`User` / `UserRole`** (`Name`, `Email`, `TimeZoneSidKey`, `UserRole.Name`) - covered by the **View All Users** system permission, not per-field FLS.
* **`Birdie_Recording__c.LinkUrl__c`** - a required field, so it's always readable and can't take an FLS entry.
  {% endhint %}

### Record visibility (sharing)

* **View All** on **Case**, **Contact**, and **Account** — so the integration user can act on records regardless of owner/sharing.

### Messaging

* Permission to send messaging notifications via the standard **`sendConversationMessages`** action (Messaging enabled + send allowed).

### Connected App OAuth scopes

`api` · `refresh_token` · `web` · `id` · `openid` · `profile` · `email` · `chatter_api`

***

*This is the full union of what Birdie uses. It deliberately excludes Modify All Data, System Administrator, Setup/admin permissions, Apex authoring, Delete on any object, and any object not listed above.*