> For the complete documentation index, see [llms.txt](https://docs.sumble.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sumble.com/system-setup-and-configuration/crm/salesforce-package/salesforce-permissions.md). # Salesforce permissions This page lists exactly what permissions Sumble needs in your Salesforce org, and — just as importantly — what it does **not** need. ## Two different users, two different permission sets These are two separate roles with different requirements: | Role | When | Needs | | -------------------- | -------------------------------- | ---------------------------------------------------------------------------------------------------- | | **Setup admin** | During install and configuration | A Salesforce administrator — `Customize Application` *or* `Modify All Data` | | **Integration user** | Every sync | **No administrator permissions.** `API Enabled` plus object/field access for the features you enable | If your org restricts connected apps to pre-authorized users ("Admin approved users are pre-authorized"), also grant the integration user access to the **Sumble** connected app via its profile or permission set. Otherwise the OAuth authorization is refused. *** ## Setup admin (one-time) The admin who installs and configures the package needs: * `Customize Application` **or** `Modify All Data`. Either one is sufficient, and either can come from the user's **profile or an assigned permission set** — you do not need to hand the person a System Administrator profile. * Salesforce itself additionally requires admin rights to install a managed package and to edit Lightning record pages (to place the Sumble widgets). If you don't want to grant the admin these permissions permanently, assign a permission set containing `Customize Application` for the duration of setup and remove it afterwards. Once setup is complete, no one needs these permissions for day-to-day use. End users see the Account widgets and the Signals tab with no Sumble-specific permission at all as the package was installed with**"Install for All Users"**, which is what grants ordinary users access to the package's components. *** ## Integration user (ongoing) ### License and profile Either of these works: * **A standard Salesforce license** with the `Minimum Access - Salesforce` profile (or your own equivalent least-privilege profile). This will consume a license. * **The `Salesforce Integration` (API-only) license** with the `Minimum Access - API Only Integrations` profile. Best practices are to grant the actual permissions through a dedicated permission set (e.g. "Sumble Integration") rather than the profile — it keeps the grant auditable and easy to revoke. #### Give the integration user an email address you can actually receive mail at Sumble's connection is authorized once through a browser-based OAuth flow, so the integration user has to get through a Salesforce login and approval screen. Email matters twice: * **Setting the password.** A new user gets a "set your password" link by email. Someone has to be able to open the link. * **Verification codes.** If Salesforce doesn't recognize the browser or IP, it emails a verification code before letting the login through. Use an address you control — an alias like `salesforce-admin+sumble@yourcompany.com` works well, and keeps the mail with whoever administers the integration. Its **Username** can be anything and doesn't have to match. Open the password link in an incognito window so it doesn't collide with your own Salesforce session, sign in as the integration user there, retrieve any verification code from your inbox, and approve the Sumble authorization. If you can't get through the authorization at all, you can switch the user to a standard license or [talk to us](#notes) and we'll work through it with you. ### Object and field permissions by feature The following features require the associated object permissions. This table will help you scope permission granularity for the integration user, if you choose. | Feature | Direction | Objects | Object permissions | | -------------------------------------------- | ------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------- | | Account list sync | Salesforce → Sumble | `Account` | Read | | Sales rep / owner sync | Salesforce → Sumble | `User` | Read | | Account team assignments | Salesforce → Sumble | `AccountTeamMember`, `User` | Read | | Contacts / champion tracking | Salesforce → Sumble | `Contact`, `Lead` | Read | | Derived fields from related records | Salesforce → Sumble | whichever object the rule queries (commonly `Opportunity`) | Read | | Enrichments written to Account fields | Sumble → Salesforce | `Account` | Read, Edit | | Enrichments written to a custom object | Sumble → Salesforce | your custom object, `Account` | Read + Create + Edit on the custom object; Read **and Edit** on `Account` | | Signals | Sumble → Salesforce | `sumble__Signal__c`, `Account` | Read + Create + Edit on `sumble__Signal__c`; Read and Edit on `Account` | | "Send to Salesforce" from the Sumble web app | Sumble → Salesforce | `Contact`, `Lead`, `Account` | Create (this uses a separate authorization — see below) | * **Enrichments to a custom object / Signals** both write to an object with a **master-detail relationship to Account**, and Salesforce requires *write* access to the parent record to create or update a detail record. So these need `Edit` on `Account`, not just `Read`, even though no Account field is being changed. * **Derived fields from related records** and the **champion-tracking query** are configured as Salesforce queries against objects of your choosing (for example, counting open opportunities per account). If your configuration uses these, the integration user needs `Read` on every object and field those queries touch as well. **Field-level security** must also be granted if they are not granted at the object level: * **Read** on every field mapped for the pull — at minimum `Id`, `Name`, `Website`, plus any `BillingCountry`, `ParentId`, owner lookup fields, and extra columns in your configuration. Also `IsDeleted` on `Contact`, and `IsDeleted` + `IsConverted` on `Lead`, which the sync filters on; and `TeamMemberRole` plus `User.Name` / `User.Email` / `User.Title` if account team assignments are synced. * **Edit** on every destination field for the push — the fields you selected in the Sumble Setup field mapping, **plus the record keys the sync writes that aren't part of your field mapping**: `External_Id__c` and `Account__c` on a custom-object target, and `Name`, `sumble__External_Id__c`, `sumble__Account__c` on `sumble__Signal__c`. If you're using a custom object for enrichments, its `External_Id__c` must be `Text(18)` and marked both **External ID** and **Unique**. ### Record visibility Object permissions control *which objects*; your sharing model controls *which records*. A least-privilege integration user owns no records, so under a Private or Public Read Only org-wide default it will see almost nothing — the sync completes "successfully" and pulls a fraction of your accounts, or push writes fail with `INSUFFICIENT_ACCESS_OR_READONLY`. Grant record access by whichever of these fits your security model: * **`View All` on `Account`** (object-level, in the permission set) for read-only features, and **`Modify All` on `Account`** if Sumble writes enrichments or Signals back. These are per-object permissions — they are *not* the org-wide `View All Data` / `Modify All Data`. * Or a **sharing rule** that shares the relevant accounts with the integration user (or a group it belongs to). Same for `Contact` / `Lead` if those are synced. Note that `sumble__Signal__c` is a master-detail child of `Account`, so its record access is inherited from the parent Account — writing Signals requires edit access to the parent accounts. ### What Sumble never needs * `Modify All Data` or `View All Data` (the per-object `View All` / `Modify All` above are narrower and are all that's needed) * `Customize Application`, `View Setup and Configuration`, or `Manage Users` * `Author Apex` or `Modify Metadata Through Metadata API Functions` — Sumble never creates or alters fields, objects, or any other metadata in your org * **Any delete permission** — Sumble never deletes your records. Writes are updates and creates only. * Access to any object beyond those in the table above. The only way that list grows is if your configuration includes a derived-field or champion-tracking query that references another object, which is something you configure with us explicitly. *** ## Troubleshooting | Symptom | Cause | | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | "Administrator Access Required" on the Sumble Setup tab or Signals gear icon | The signed-in user has neither `Customize Application` nor `Modify All Data`. Note the check is cached — retest in a fresh incognito window after granting. | | Integration user can't get through the OAuth login/approval screen | The set-your-password link or the verification code went to a mailbox nobody can open. See [Give the integration user an email address you can actually receive mail at](#give-the-integration-user-an-email-address-you-can-actually-receive-mail-at). Affects the one-time authorization only, not ongoing syncing. | | OAuth authorization refused | The Sumble connected app is restricted to pre-authorized users and hasn't been granted to this user. | | `API_DISABLED_FOR_ORG` or API calls rejected outright | `API Enabled` missing from the integration user's profile/permission set. | | Sync returns far fewer accounts than the org contains | Record visibility, not object permissions — see [Record visibility](#record-visibility). | | `INSUFFICIENT_ACCESS_OR_READONLY` on push | Missing `Edit`/`Modify All` on `Account`, or missing field-level `Edit` on a mapped destination field. | | `INVALID_FIELD` on push | Field-level Read/Edit not granted on a mapped field, or the field doesn't exist on the target object. | | Enrichments write, but no Signals appear | Missing `Read`/`Create`/`Edit` on `sumble__Signal__c`, or no edit access to the parent accounts. | | A single derived-field column is always empty, with no error | The query behind it references an object or field the integration user can't read. These fail quietly by design so one bad column can't stop the whole sync. | | End users see "You do not have access to the Apex class…" | The package was installed for admins only rather than with **Install for All Users**. | | `INVALID_FIELD` naming `External_Id__c` on a custom-object target | The field is missing, or isn't `Text(18)` marked External ID **and** Unique. | *** ## Notes * Bulk API 2.0 is required, so Salesforce **Enterprise Edition or higher** is needed. * If your org enforces **Login IP Ranges**, note that Sumble's syncs run from Google Cloud and we do not currently publish a fixed egress IP range — talk to us before applying an IP restriction to the integration user. * The web app's "Send to Salesforce" action uses its own authorization, separate from the sync integration user, and can be pointed at a different Salesforce user if you want record creation attributed separately. Book a time to chat with us