Integration User
An Integration User in Salesforce is a dedicated user account whose sole purpose is to serve as the identity that external systems authenticate as when calling Salesforce APIs.
Definition
An Integration User in Salesforce is a dedicated user account whose sole purpose is to serve as the identity that external systems authenticate as when calling Salesforce APIs. The integration user owns the OAuth refresh token, the JWT certificate, or the Connected App credentials used by the external system. Salesforce introduced the Salesforce Integration license in 2023 as the official license type for these users, replacing the prior practice of dedicating a full standard user license to an integration account.
The Integration User License is restricted: it allows access only through APIs, not through the standard UI; it has a limited subset of standard objects (Account, Contact, Opportunity, Case, Lead, Task, Event, plus selected others); and it is priced at a fraction of a standard Sales or Service license. The license is the recommended approach for any non-human integration identity. Existing orgs running integrations under standard licenses can swap to Integration User licenses to free up the standard seats, with limited migration work required.
The Integration User license model and why it exists
Why a dedicated integration identity matters
Integrations should authenticate as a dedicated user, not as a real person. Using a real user means the integration breaks when the person leaves; their session token rotates; and audit trails attribute external-system actions to them, polluting the legitimate-activity log. The integration user solves all three problems by being a permanent, dedicated identity owned by the integration itself.
The Salesforce Integration License (2023+)
Salesforce released the Integration User License in 2023 specifically for this use case. The license is API-only (no UI access), supports the standard objects most integrations need, and prices at a steep discount versus a standard Sales or Service license. Each org gets a small allocation of Integration Licenses included with their Salesforce contract; additional licenses are available for purchase.
Object access on Integration Licenses
The Integration License includes Account, Contact, Lead, Opportunity, Case, Task, Event, Custom Objects, ContentDocument, ContentVersion, and selected others. It excludes some Service Cloud-specific and Industries-specific objects; check the Edition Comparison page before assigning. Custom objects are accessible by default; permissions are controlled by the Integration User Permission Set assignment.
Connected App and OAuth setup
Most integrations use a Connected App with OAuth 2.0 JWT Bearer Flow, which authenticates without a user-interactive consent screen. The integration user is configured as the run-as user on the Connected App; the external system presents a signed JWT, Salesforce validates it, and returns an access token that runs in the integration user''s context. The JWT-based flow is recommended over username-password for production integrations.
Permission sets and least privilege
Integration users should follow least-privilege: grant only the objects and fields the integration actually needs. Standard practice is a custom Permission Set named after the integration (e.g., HubSpot Integration Permissions) listing the exact object access, field-level permissions, and Apex class access. The integration user has the Integration License profile plus this permission set.
Auditing integration user activity
The Setup Audit Trail and the Login History both record integration user activity. Salesforce Shield Event Monitoring extends this to API call logs. Filtering activity by integration user surfaces precisely what external systems did, separated from real-user activity. This separation is the single largest operational benefit of using a dedicated integration user.
Migration from standard-licensed integration users
Existing orgs may have integration accounts running on standard Sales or Service licenses. Migration to Integration License is straightforward: assign the new license to a new user, copy the OAuth credentials to the new user (which usually means generating new tokens for the external system), test the integration, retire the old user. The savings on the standard license offset the migration effort.
Create a dedicated Integration User for a new integration
The setup flow is the same for every new integration: license, user, permission set, Connected App, OAuth tokens.
- Confirm available Integration Licenses
Setup, Company Information. Check the license allocation; each org gets a small free allocation, more can be purchased.
- Create the User record
Setup, Users, New User. Assign the Integration License profile, set a strong password or disable interactive login, and pick a generic email like integration-hubspot@yourcompany.com.
- Build a least-privilege Permission Set
Create a Permission Set with exactly the objects, fields, and Apex classes the integration needs. Assign it to the integration user.
- Create a Connected App
Setup, App Manager, New Connected App. Enable OAuth, choose JWT Bearer Flow, upload the certificate the external system will sign with. Authorize the Connected App for the integration user.
- Test the OAuth flow
From the external system, request an access token using the JWT flow. Verify the token comes back and the API call succeeds.
- Document the integration
Record the integration user, Connected App name, JWT certificate location, and intended object access in a runbook. Future admins will thank you.
The user license type that grants API-only access.
Least-privilege object and field permissions.
The OAuth trust object the external system authenticates against.
Required for the JWT Bearer Flow.
Integration users should not log in interactively.
- Integration License has a restricted object list. Confirm every object the integration needs is supported before assigning the license.
- Each org gets a small free Integration License allocation. Hitting the cap requires purchasing additional licenses through the Salesforce account team.
- JWT Bearer Flow requires the external system to maintain a certificate. Lost certificates require revoking and re-issuing, which interrupts the integration.
- Integration users without strong governance can drift into excess permissions over time. Audit Permission Set assignments quarterly.
Trust & references
Cross-checked against the following references.
- Salesforce User License TypesSalesforce Help
- Connected AppsSalesforce Help
Straight from the source - Salesforce's reference material on Integration User.
- OAuth 2.0 JWT Bearer FlowSalesforce Help
Hands-on resources to go deeper on Integration User.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an Integration User?
Q2. Why use dedicated integration users?
Q3. What's a best practice for integration user permissions?
Discussion
Loading discussion…