Salesforce Integration User Testing
Salesforce integration user testing confirms that the API and automation identities connecting your org to middleware, ERP, data platforms and managed packages are scoped to exactly what each integration needs. It proves the identity can perform its contracted operations on its objects, fields and records — and that it is denied everything else, so a leaked credential or a misbehaving job cannot roam the org.
Integration identities are often the broadest, least-reviewed accounts in an org, which makes them a priority for access validation.
What an integration identity is in Salesforce
An integration identity is any user that systems, not people, log in as. Historically many orgs used a full Salesforce license with a cloned System Administrator profile for this. Salesforce now offers a dedicated Salesforce Integration user license for API-only access, paired with the Minimum Access - API Only Integrations profile and the Salesforce API Integration permission set license, so integration access can be granted through permission sets on a deliberately empty baseline. The API Only User permission prevents these identities from logging in to the user interface.
How the identity authenticates shapes what has to be tested. Inbound integrations typically use a connected app with the OAuth JWT bearer flow or the client credentials flow, where the connected app names a run-as user. Outbound callouts use named credentials and external credentials, where access to the external credential's principal is itself granted through permission sets. Packaged integrations often create their own users and permission sets on install.
Integration user testing validates the effective access of each of these identities as a persona. It sits beside API testing, which proves the integration's data is correct, and concentrates on whether the identity has the right rights — no fewer, no more.
Integration identity types and what to validate
Each identity pattern carries a different access footprint and a different set of checks.
| Identity pattern | How it connects | Access to validate |
|---|---|---|
| Middleware sync user | Connected app with JWT bearer flow from MuleSoft or an iPaaS | Only the synchronized objects and mapped fields, with the intended create, update and upsert rights |
| Client credentials run-as user | Connected app issues tokens for a designated run-as user | The run-as user is API-only and scoped, since every token inherits its access |
| Data platform extract user | Bulk API reads for warehouse or lake loads | Read-only on extracted objects; no edit, delete or View All beyond the extract scope |
| Outbound callout principal | Named credential with an external credential principal | Only the permission sets meant to use the principal can invoke the callout |
| Managed package integration user | Created or configured by an installed package | Package-assigned permission sets grant no objects beyond the package's documented needs |
| Batch load user | Data Loader or scheduled ETL jobs | Write rights limited to load targets, with record ownership and sharing behaving as designed |
How integration access drifts
Integration users rarely start over-provisioned on purpose. Access grows through convenience, and nothing breaks to signal it.
Admin profile by default
An integration built quickly under a System Administrator clone inherits Modify All Data, Customize Application and Manage Users that no data sync needs.
View All and Modify All shortcuts
Granting View All or Modify All on an object to get past a sharing error bypasses record-level sharing entirely for that identity.
One user, many integrations
Several systems sharing a single integration user accumulate the union of all their needs, and no one can retire a permission safely.
Standing credentials and loose login policy
No login IP ranges, non-expiring secrets and broadly pre-authorized connected apps let a leaked credential be used from anywhere.
Orphaned permissions
When an integration is retired or remapped, the permission sets that served it stay assigned and keep the old access alive.
System-mode Apex endpoints
Custom Apex REST services called by the integration can act without sharing, extending its reach past what its permissions suggest.
Scoping and testing an integration user
The goal is a written integration access contract that the tests enforce in both directions.
Write the access contract
For each integration, list the objects, fields and operations it performs, the records it should touch and how it authenticates, using real payloads and mappings as the source.
Resolve effective access
Combine the identity's profile, permission sets, permission set groups and permission set licenses to see its actual rights, including View All, Modify All and system permissions.
Run the contracted operations
Execute each query, insert, update, upsert and delete the integration performs as that identity, confirming all succeed with representative data.
Run deny calls
As the same identity, attempt operations outside the contract — other objects, restricted fields, deletes, user administration, metadata calls — and pass only on a clean block.
Check login and session policy
Confirm the identity cannot log in to the user interface, and that IP restrictions and connected app policies reject tokens from unexpected contexts where configured.
Retain evidence and re-baseline
Store each call, identity, expected result and outcome, and update the contract whenever the integration's mappings change.
Deny assertions every integration suite should include
These checks catch the broad rights integration identities most commonly carry without needing them.
- Querying an object outside the integration's mapping returns an access error rather than rows.
- Updating a field that the integration only reads fails with an insufficient access response.
- Deleting records is blocked unless deletion is part of the documented contract.
- Creating or editing users, permission sets or assignments is blocked for the identity.
- Metadata and Tooling API calls that deploy or change configuration are blocked for data-only integrations.
- Records owned by other business units are not returned when the integration's scope is record-limited by sharing.
- Interactive login to the Salesforce user interface is refused for API-only identities.
- Exporting data through reports or the Bulk API beyond the extract scope is blocked for read-limited extract users.
Moving integrations to least privilege safely
Many teams now want to move integrations off full licenses and administrator profiles onto the Salesforce Integration user license with permission-set-based access. The risk is not the security improvement; it is breaking a production sync because one field or object right was missed. Integration user testing makes that migration measurable: run the contracted operations under the old identity, build the narrower identity in a sandbox, run the same operations and deny calls against it, and only cut over when both sets pass.
The same approach applies after any integration change. When a MuleSoft mapping adds a field or a new object joins a Bulk API load, the access contract and its tests change with it. That keeps least privilege current rather than letting the identity widen each time a developer hits an access error under deadline.
Evidence and what SyntraFlow is designed to do
These capabilities are available for demonstration and proof-of-concept validation against your own integration identities.
Identity-as-persona testing
SyntraFlow is designed to execute API operations as the integration identity itself, so results reflect its effective rights rather than an administrator's.
Contract-driven deny calls
Scenarios can be configured from the integration access contract so every operation outside it is attempted and expected to fail.
Service account review evidence
Runs can retain the identity, call, expected outcome and result, supporting periodic service account access reviews with proof.
Cross-system view
Because SyntraFlow is Oracle-native, tests can be scoped to follow an integration identity's writes into connected back-office systems during a proof of concept.
Integration user test scenarios
Representative scenarios for a typical middleware and data platform landscape.
| Scenario | What it proves |
|---|---|
| ERP sync user upserts Account and Order by external ID | The contracted write path works under the scoped identity |
| ERP sync user attempts to delete an Opportunity | Delete rights were not granted beyond the contract |
| Extract user queries Contact with a restricted national ID field | Field-level security applies to the integration identity too |
| Client credentials token used for a metadata deploy | The run-as user cannot change configuration |
| Integration user attempts interactive login | API Only User enforcement blocks UI access |
| Retired marketing sync permission set still assigned | Orphaned access is detected and flagged for removal |
| Integration moved to the Integration user license | All contracted operations still pass on the narrower identity |
Related pages
Salesforce security testing
The hub for persona-based access validation, including non-human identities.
Salesforce API testing
Validates the data and behavior of the API calls integration users make.
MuleSoft testing
Tests Anypoint-brokered flows that commonly run under an integration identity.
Permission set testing
Tests the permission sets that grant integration access on an API-only baseline.
Segregation of duties
Detects identities that combine conflicting capabilities, including service accounts.
Negative access testing
The deny-case method used for every out-of-contract integration call.
Integration User Testing testing FAQs
What is Salesforce integration user testing?
It is the validation that API and automation identities have exactly the access their integrations need. Tests run the integration's contracted operations as that identity to prove they work, then attempt operations outside the contract to prove they are blocked.
What is the Salesforce Integration user license?
It is a license designed for system-to-system, API-only access. It pairs with the Minimum Access - API Only Integrations profile and the Salesforce API Integration permission set license, so access is granted through permission sets on a minimal baseline rather than through a full user profile.
Why is a System Administrator profile risky for integrations?
It carries system permissions such as Modify All Data, Customize Application and Manage Users that data integrations do not need. If the credential leaks or the integration misbehaves, those rights allow changes across the entire org, bypassing sharing and field-level restrictions.
Do connected app policies replace integration user testing?
No. Connected app policies control how tokens are issued and who is pre-authorized, but every token still acts with the run-as or authenticated user's access. Testing that user's effective rights is what proves the blast radius of a token is small.
How do you migrate an integration to least privilege without breaking it?
Document the integration's contract, build the narrower identity in a sandbox, and run the full set of contracted operations and deny calls against it. Cut over only when every contracted operation passes and every out-of-contract call is blocked, then keep the suite as a regression check.
Does SyntraFlow provide a connector for my middleware platform?
SyntraFlow is designed to validate integration identities from the Salesforce side by executing API operations as those identities. Reading middleware artifacts directly is an integration opportunity that can be scoped during a proof of concept rather than a shipped connector.
Shrink the blast radius of every service account
See how integration user testing proves each API identity does its job and nothing more.