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:
Object and field permissions for each enabled workflow.
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
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
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
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
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
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.
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.
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
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
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
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.
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 DataModify All DataView All FieldsModify MetadataView Setup and ConfigurationView Roles and Role Hierarchy
Administration and end-user features
The following capabilities should be assigned separately from the headless integration-user baseline:
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:
Grant the fixed object and field access required by the workflow.
Add configured standard, custom and managed-package fields to a customer-managed extension permission set.
Review the workflow’s Account and related-object relationships.
Confirm that Salesforce sharing gives the integration user access to the complete record population.
Add object-specific
View All RecordsorModify All Recordsonly where sharing is insufficient.Test the workflow with the integration user.
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.
Last updated

