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 [e-mail] 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 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. 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.
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