> For the complete documentation index, see [llms.txt](https://docs.kernel.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kernel.ai/integrations/salesforce-integration/salesforce-integration-user-permission-matrix.md). # Salesforce Integration User Permission Matrix This page defines the least-privilege access required by the Kernel Salesforce integration user. Permissions depend on the workflows enabled in your Kernel configuration. The integration user requires: 1. Object and field permissions for each enabled workflow. 2. Record-level access to the records included in that workflow. These are separate requirements. Object permissions do not automatically give the integration user access to every record. ### Permission sources | Permission source | Description | | -------------------------- | ------------------------------------------------------------------------------------------------------ | | **Kernel baseline** | Fixed access required by Kernel for standard workflows and packaged fields. | | **Standard conditional** | Standard Salesforce access required only when the corresponding workflow or feature is enabled. | | **Customer extension** | Customer-selected standard fields, custom fields, managed-package fields and related objects. | | **Customer record access** | Sharing rules, ownership, role hierarchy or object-specific `View All Records` / `Modify All Records`. | Object permissions are abbreviated as: * **R** — Read * **C** — Create * **E** — Edit * **D** — Delete Field permissions are shown as **Read** or **Edit**. ### Connect Kernel to Salesforce | Workflow | Object or resource | Fields | Permissions needed | Permission source | | -------------------------------------------------- | --------------------------------------------------- | ------ | ----------------------------------------------------------- | ------------------------------------------------------------------ | | Connect through the Salesforce API | Salesforce API | — | `API Enabled` | Kernel baseline | | Use a Kernel REST endpoint | Relevant Kernel Apex REST class | — | Apex Class Access for the endpoint being used | Kernel baseline | | Authorize the connected application | Kernel Connected App | — | Connected App authorization and the configured OAuth scopes | Salesforce connection configuration | | Make outbound requests from the Salesforce package | Kernel external credential | — | External Credential Principal Access | Standard conditional | | Configure Kernel in Salesforce | Kernel setup controllers and configuration metadata | — | Separate administrator permission set | Human administrator; not part of the headless integration baseline | ### Pull and clean CRM records | Workflow | Object | Fields | Permissions needed | Permission source | | ------------------------------- | ----------- | ---------------------------------------------------------------------------------------------- | -------------------------------------------------- | -------------------------------------------------------------------------- | | Pull and clean Accounts | Account | `Id`, `Name`; `Website` where used; every configured pull, filter, matching and cleaning field | Account R; listed fields Read | Kernel baseline for fixed fields; Customer extension for configured fields | | Calculate Account-level rollups | Account | `Id`, `OwnerId`, `LastActivityDate`, `CreatedDate` and enabled rollup fields | Account R; listed fields Read | Standard conditional | | Pull Leads | Lead | Every field selected for pull, matching, filtering or output | Lead R; selected fields Read | Standard conditional and Customer extension | | Read related Contacts | Contact | `Id`, `AccountId` and configured Contact fields | Contact R; listed fields Read | Standard conditional and Customer extension | | Read related Opportunities | Opportunity | `Id`, `AccountId` and configured Opportunity fields | Opportunity R; listed fields Read | Standard conditional and Customer extension | | Read related Tasks | Task | `Id`, `AccountId` and configured Task fields | Task R; listed fields Read | Standard conditional and Customer extension | | Read Account owners | User | `Id`, `Name`, `Email`, `IsActive` and configured owner fields | Visibility of the required User records and fields | Standard conditional | The integration user must be able to see every record included in a pull or rollup. Use customer sharing rules where possible. If sharing cannot provide complete visibility, grant `View All Records` only on the relevant object. ### Create and manage Account hierarchies | Workflow | Object | Fields | Permissions needed | Permission source | | ------------------------------------------------------ | ------- | ----------------------------------------------------------------- | ----------------------------------------- | ---------------------------------- | | Find an existing parent | Account | `Id`, `Name`, `Website` | Account R; listed fields Read | Kernel baseline | | Create a minimum parent Account | Account | `Name`, `Website` | Account C; populated fields Edit | Kernel baseline | | Populate a standard billing address | Account | `BillingStreet`, `BillingCity`, `BillingPostalCode` | Account C; populated fields Edit | Standard conditional | | Populate geography without State and Country Picklists | Account | `BillingState`, `BillingCountry` | Account C; populated fields Edit | Standard conditional | | Populate geography with State and Country Picklists | Account | `BillingCountryCode` | Account C; field Edit | Standard conditional | | Populate configured parent fields | Account | Every customer-selected standard, custom or managed-package field | Account C; populated fields Edit | Customer extension | | Set, change or remove the standard parent | Account | `ParentId` | Account R/E; `ParentId` Read/Edit | Kernel baseline | | Use a custom hierarchy relationship | Account | Configured relationship field | Account R/E; relationship field Read/Edit | Customer extension | | Roll back a reparent | Account | The same relationship field used by the original action | Account E; relationship field Edit | Same source as the original action | The integration user also needs edit access to every Account being reparented. For cross-owner mass actions, this can be supplied through sharing or through Account `Modify All Records`. ### Merge Accounts | Workflow | Object | Fields | Permissions needed | Permission source | | ---------------------------------- | ------- | ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Read master and duplicate Accounts | Account | `Id`, `Name` and every matching or survivorship source field | Account R; listed fields Read | Kernel baseline and Customer extension | | Back up Accounts before merge | Account | Every field expected in the backup | Account R; expected backup fields Read | Kernel baseline for fixed fields; Customer extension for additional fields | | Apply survivorship values | Account | Every configured survivorship field | Account E; source fields Read; target fields Edit | Customer extension | | Preserve or repair the hierarchy | Account | `ParentId` | Account R/E; `ParentId` Read/Edit | Standard conditional | | Apply owner survivorship | Account | `OwnerId` | Account E; ability to assign the selected owner; additional transfer permissions where required | Standard conditional | | Merge the Accounts | Account | Record IDs | Account R/E/D; edit access to the master; delete access to losing Accounts | Kernel baseline plus Customer record access | Salesforce requires Delete permission on Account to merge Accounts. It can also require edit access to related records such as Contacts and Opportunities. `Modify All Records` on Account is not mandatory when ownership and sharing provide sufficient access. It can, however, be the most practical customer-controlled option for mass merges spanning many owners. #### Account backup field access Kernel’s Account backup includes fields available to the integration user. `View All Fields` is not required to run a merge, but Kernel cannot back up a field that the integration user cannot read. Grant Read access to every Account field that you expect Kernel to preserve in the backup. ### Related Object Safeguards A Related Object Safeguard counts records connected to an Account through a configured relationship and uses that count to determine whether the Account should be safeguarded. | Workflow | Object | Fields | Permissions needed | Permission source | | ---------------------------------------------- | -------------------------- | ------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------ | | Evaluate a standard related-object safeguard | Configured standard object | Configured Account relationship field | Object R; relationship field Read; visibility of records that must be counted | Standard conditional plus Customer record access | | Evaluate a custom or managed-package safeguard | Configured object | Configured Account relationship field | Object R; relationship field Read; visibility of records that must be counted | Customer extension plus Customer record access | Safeguard counts cover only objects and records visible to the integration user. If normal sharing does not provide complete visibility, grant `View All Records` on that specific related object. A safeguard is separate from backup and delete-before-merge configuration: * **Safeguards** count related records and protect Accounts from an action by default. * **Backup Objects** determine which related records Kernel captures. * **Delete-before-merge** determines which related records Kernel explicitly deletes. * Objects not handled explicitly remain subject to Salesforce’s native merge behaviour. Before enabling Account merges, review the relevant standard, custom and managed-package Account relationships with your Salesforce administrator. ### Back up related records Contact, Opportunity and Task are included in the default Backup Objects configuration. Customers can change this list. | Workflow | Object | Fields | Permissions needed | Permission source | | ------------------------------------------ | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------- | | Back up Contacts | Contact | `AccountId` and every field expected in the backup | Contact R; listed fields Read | Standard conditional | | Back up Opportunities | Opportunity | `AccountId` and every field expected in the backup | Opportunity R; listed fields Read | Standard conditional | | Back up Tasks | Task | `AccountId` and every field expected in the backup | Task R; listed fields Read | Standard conditional | | Back up another standard object | Configured standard object | Account relationship field and every field expected in the backup | Object R; listed fields Read | Customer-selected conditional | | Back up a custom or managed-package object | Configured object | Account relationship field and every field expected in the backup | Object R; listed fields Read | Customer extension | | Back up Account history | `AccountHistory`, only when selected | Fields visible to the integration user, including applicable history details such as `AccountId`, `CreatedDate`, `Field`, `OldValue` and `NewValue` | Account R; visibility of affected Accounts; access to the tracked Account fields whose history is required | Customer-selected conditional | Kernel’s current backup process requests the fields available to the connected user. Fields hidden by field-level security are not included. `AccountHistory` is not a baseline requirement. It is read only when it has been added to the Backup Objects configuration. ### Handle related records during merge | Workflow | Object | Fields | Permissions needed | Permission source | | -------------------------------------------------------------------- | ------------------------------------------- | --------------------------------------------------------------- | --------------------------------------------------------------------- | ------------------------------------------ | | Allow Salesforce to handle related Contacts during native merge | Contact | `AccountId` | Contact R/E; `AccountId` Read/Edit where Salesforce requires it | Standard conditional | | Allow Salesforce to handle related Opportunities during native merge | Opportunity | `AccountId` | Opportunity R/E; `AccountId` Read/Edit where Salesforce requires it | Standard conditional | | Allow Salesforce to handle another standard child relationship | Case, Contract or another applicable object | Account relationship field | Object R/E and relationship Read/Edit where required by Salesforce | Standard conditional | | Clean duplicate Account–Contact relationships | `AccountContactRelation` | `Id`, `AccountId`, `ContactId`, `IsDirect` | AccountContactRelation R/D; listed fields Read | Standard conditional | | Reparent a direct Contact during relationship cleanup | Contact | `AccountId`; `OwnerId` where an inactive owner must be replaced | Contact R/E; `AccountId` Edit; ownership permissions where applicable | Standard conditional | | Delete configured related records before merge | Any configured deletable object | `Id`, Account relationship field and backup fields | Object R/D; listed fields Read; delete access to affected records | Standard conditional or Customer extension | Kernel does not explicitly reparent every related-object type. Salesforce’s native merge processing may move or retain related records according to Salesforce’s own merge rules. ### Roll back failed actions | Workflow | Object | Fields | Permissions needed | Permission source | | -------------------------------------------------- | ------------------------- | ----------------- | ------------------------------------------------------------------------ | ------------------------------------------- | | Revert an Account hierarchy repair | Account | `ParentId` | Account E; `ParentId` Edit | Standard conditional | | Restore a losing Account deleted during merge | Account | Record ID | Account D and access required to restore the record from the Recycle Bin | Kernel baseline plus Customer record access | | Restore a related record Kernel explicitly deleted | Configured related object | Record ID | Object D and access required to restore the record from the Recycle Bin | Standard conditional or Customer extension | | Restore a field Kernel explicitly changed | Account or related object | The changed field | Object E; field Edit | Same source as the original change | Rollback is best effort and depends on the affected records remaining available in the Salesforce Recycle Bin. It does not reconstruct every side effect performed by Salesforce’s native merge process. ### Link and sync records | Workflow | Object | Fields | Permissions needed | Permission source | | ----------------------------------- | ------------------------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------- | | Link an Account to a Kernel Account | Account | `Kernel_Account__c`; `Kern_Id__c` where used | Account R/E; fields Read/Edit | Kernel baseline | | Store the reverse Account link | `Kernel_Account__c` | `Linked_Account_Field__c` | Kernel Account R/E; field Read/Edit | Kernel baseline | | Sync Account to Kernel Account | Account | `Id`, `Name`, `Kernel_Account__c` and every mapped source field | Account R; source fields Read; Account E and `Kernel_Account__c` Edit when writing the backlink | Kernel baseline and Customer extension | | Create a missing Kernel Account | `Kernel_Account__c` | `Name`, `Kernel_ID__c`, `Linked_Account_Field__c` and mapped target fields | Kernel Account C; target fields Edit | Kernel baseline and Customer extension | | Update a Kernel Account | `Kernel_Account__c` | `Linked_Account_Field__c` and mapped target fields | Kernel Account R/E; match field Read; target fields Edit | Kernel baseline and Customer extension | | Sync Kernel Account to Account | `Kernel_Account__c` and Account | Configured source and target fields | Kernel Account R; Account R/E; source fields Read; target fields Edit | Kernel baseline and Customer extension | Delete permission on `Kernel_Account__c` is not a normal integration-user requirement. ### Record-level access for mass actions CRUD and field permissions do not bypass Salesforce sharing. | Operation | Minimum record access | Practical mass-action option | | ---------------------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | Pull, safeguard or back up records | Read access to every record in scope | Customer sharing rules or object-specific `View All Records` | | Reparent or update Accounts | Edit access to every affected Account | Customer sharing/ownership or Account `Modify All Records` | | Merge Accounts | Edit access to the master and delete access to losing Accounts | Customer sharing/ownership or Account `Modify All Records` | | Reparent related records | Edit access to every affected related record | Customer sharing or `Modify All Records` on that object | | Delete related records | Delete access to every affected related record | Customer sharing/ownership or `Modify All Records` on that object | | Change ownership | Access to the source record and selected owner, plus any Salesforce transfer permissions | Conditional ownership-transfer permissions | For broad cross-owner mass actions, object-specific `View All Records` or `Modify All Records` can be an appropriate least-privilege choice. These permissions should be granted only on the objects involved. They do not require the integration user to receive: * System Administrator * `View All Data` * `Modify All Data` * `View All Fields` * `Modify Metadata` * `View Setup and Configuration` * `View Roles and Role Hierarchy` ### Administration and end-user features The following capabilities should be assigned separately from the headless integration-user baseline: | Capability | Intended user | | ------------------------------------------------------ | ------------------------------ | | Install or upgrade the Kernel package | Salesforce administrator | | Configure Connected App policies and OAuth | Salesforce administrator | | Create or change sync configuration metadata | Salesforce administrator | | Manage schedules and setup settings | Salesforce administrator | | Access Kernel setup tabs or configuration applications | Salesforce administrator | | Submit feedback from the Salesforce UI | Human Salesforce user | | View or administer application logs | Support or administrative user | ### Setup checklist Before enabling a Kernel workflow: 1. Grant the fixed object and field access required by the workflow. 2. Add configured standard, custom and managed-package fields to a customer-managed extension permission set. 3. Review the workflow’s Account and related-object relationships. 4. Confirm that Salesforce sharing gives the integration user access to the complete record population. 5. Add object-specific `View All Records` or `Modify All Records` only where sharing is insufficient. 6. Test the workflow with the integration user. 7. Repeat the review after changing survivorship rules, backup objects, safeguards, sync mappings, Salesforce sharing or schema. ### Permissions not required by current workflows `SetupAuditTrail` is not queried by Kernel’s current integration workflows and is not a runtime permission requirement. If Salesforce attributes `SetupAuditTrail` activity to the Kernel integration user, provide Kernel Support with: * The timestamp and timezone * The integration-user ID * The Connected App or OAuth client ID * The observed query or request URI, where available This information allows the source of the activity to be traced without granting additional administrative permissions.