Salesforce Integration User: License, Setup and Best Practices (2026)

What a Salesforce integration user is, and why it matters

A Salesforce integration user is a user record that no person logs in as. An external system (an ERP, a marketing platform, a data warehouse, a phone system) authenticates as that user and calls the Salesforce API. Every record it reads or writes is checked against that user’s permissions and stamped with its name.

That makes the integration user your main control point. Salesforce Help puts the recommendation plainly: following the principle of least privilege, create and configure one Salesforce user for every integration. Its reasons:

• Scope. Each user sees only the subset of data and functions its integration needs.
• Traceability. Created By, Last Modified By, login history and API logs point to one system, not “Admin.”
• Blast radius. If one vendor is breached or one secret leaks, you shut off one user and one app, not all of them.

The common anti-pattern is the opposite: one admin’s login (or one shared “integration@” user with System Administrator) used by five tools. It works until that person leaves, a password expires, or a single compromised token exposes the whole org.

The Salesforce Integration user license, explained

Salesforce sells a user license made for this job, called Salesforce Integration. According to Salesforce Help, as of October 2026 it works like this:

• Editions: available in Enterprise, Unlimited, Performance and Developer editions.
• Included licenses: orgs in supported editions are granted a limited number of Salesforce Integration user licenses by default. For more, Salesforce says to contact your account executive about add-on licenses.
• API only: users with this license are not authorized to access Salesforce data or features through any user interface. They connect through the REST, SOAP or Bulk APIs.
• What it unlocks: the Minimum Access - API Only Integrations profile and the Salesforce API Integration permission set license.

To see what you have, open Setup, then Company Information. Salesforce Integration appears under User Licenses (total and used), and Salesforce API Integration under Permission Set Licenses.

The Minimum Access - API Only Integrations profile

This profile enables API access and restricts the user to API access. You can’t turn off those two settings, including on clones of the profile, but you can change its other permissions, settings and data access. Salesforce’s developer blog describes it as based on the Minimum Access - Salesforce profile, with only the bare minimum.

It replaced the older Salesforce API Only System Integrations profile in Spring ’24, after a known issue where the old one granted access to custom objects it shouldn’t have. New orgs only get the new profile. If your org is older and integration users still sit on the old profile, Salesforce recommends moving them.

One detail is easy to miss: Salesforce Help notes that users with this profile can also access objects that are accessible to all users. Review the profile in your own org before you assume it grants nothing.

The Salesforce API Integration permission set license

On its own, the profile gives the user almost nothing to work with. The Salesforce API Integration permission set license extends the Integration license with many of the user and object permissions available on the standard System Administrator profile.

The key word is available. The permission set license only makes permissions grantable; it doesn’t grant them. You still create a permission set tied to this license, switch on exactly the object, field and system permissions the integration needs, and assign it.

Some integrations need other permission set licenses too (for example for an industry cloud or a managed package), and Salesforce notes that not every one can be assigned to an Integration-licensed user.

License options compared

The Integration license is the default choice, but not the only one. Here are the realistic options for the user an integration logs in as:

Salesforce doesn’t publish a public list price for add-on Integration licenses, so get a quote from your account executive. Compare it with what each extra integration would cost you as a full seat, and with the cost of an incident on a shared admin user.

How the pieces fit together

An integration user is never set up alone. The external system authenticates through an OAuth app, the token acts as the integration user, and the user’s license, profile and permission sets decide what each API call may touch.

How to set up a Salesforce integration user, step by step

Start in a sandbox: Salesforce’s own admin guidance recommends configuring the API-only profile there before production. The steps run from inventory to monitoring, because the user is only as safe as the access you can account for. Salesforce Help has the current clicks, since menu labels move between releases.

1. List your integrationsEvery system that calls Salesforce today, which user it logs in as, and what it reads and writes. Shared admin logins and “integration@” users with System Administrator are the first to replace.
2. Check your licensesSetup, Company Information: count available Salesforce Integration user licenses and Salesforce API Integration permission set licenses. If you have more integrations than licenses, decide which get one first, and ask your account executive about add-ons.
3. Get the vendor’s requirementsAsk each vendor which objects, fields and permissions their connector needs, whether it supports the Integration license, which OAuth flow it uses, and its published IP ranges. Many document this in their setup guide.
4. Clone the profile per integrationMake a copy of Minimum Access - API Only Integrations for each external application, check it carries no extra permissions, and set its Login IP Ranges to the vendor’s ranges. Salesforce’s admin blog recommends exactly this, so even a stolen token can’t be used from elsewhere.
5. Create the userSetup, Users, New User. Pick the Salesforce Integration user license and your cloned profile. Name it after the system (“ERP Integration”), and use a team mailbox you control as the email, because the account still has to be verified. After verification, Salesforce shows that access is restricted for API-only users, which is what you want.
6. Create a permission set for that integrationChoose Salesforce API Integration as its license, then grant only the object, field and system permissions from step 3. Assign it to the user. Use a permission set group if several integrations share a base and differ in a few permissions.
7. Create the OAuth appCreate an External Client App with OAuth enabled, the narrowest scopes that work, and the flow the integration uses. For client credentials, enable the flow and set your integration user as the run-as user; Salesforce notes that Permitted Users policies don’t apply to this execution user, so its own permissions are the real limit. For flows such as JWT bearer, set Permitted Users to admin-approved and pre-authorize only the integration user’s profile or permission set. Store the secret in a secrets manager.
8. Test with the minimumRun every real scenario: create, update, delete if allowed, bulk loads, error cases. When something fails with an access error, add that one permission, not a whole bundle. Expect a little trial and error.
9. Deploy and re-checkMove the profile, permission sets and app to production, then compare the production profile against what you tested; Salesforce’s admin blog warns that permissions can sneak back in during deployment. Keep the old access model for a month or two before deleting it, in case you need to roll back.
10. Switch on monitoringNote the user in your runbook with its owner, vendor contact and secret rotation date, and set up the checks in the monitoring section below.

Permission mapping: which integration gets what

Least privilege only works if you write the permissions down per integration. Use this as a starting template, then cut it to what your vendor documents. The rows are typical examples, not vendor requirements.

Three permissions deserve a second look in any integration permission set: View All Data, Modify All Data and Customize Application. A vendor that asks for them usually means “we didn’t test with less.” Push back, test with object-level access, and grant the broad permission only if the connector truly fails without it.

Remember field-level security too: an integration that only needs an email and a status shouldn’t read salary or credit-limit fields.

Record access matters as much as object access. The integration user is still subject to sharing rules and organization-wide defaults. If an ERP must update every account, give it View All or Modify All on Account only, rather than a role at the top of the hierarchy or org-wide View All Data.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→Healthcare+30%lab test ordersMedical Lab Web and Native Mobile Applications→Retail · Startup700+stores aggregatedMobile application for Grocery shops→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Authentication: External Client Apps, OAuth flows and MFA

Salesforce Help says integrations on a REST-based API should authenticate through an external client app and an OAuth 2.0 flow. SOAP-based integrations, including Bulk API, use the SOAP login() call. Two 2026 changes shape that choice:

• New connected apps are restricted. According to Salesforce’s developer documentation, connected app creation is restricted as of Spring ’26. Existing connected apps keep working, but Salesforce recommends External Client Apps for new integrations, and re-enabling connected app creation requires a request to Salesforce Support.
• Legacy password logins are being phased out. Salesforce’s Spring ’26 architect guidance says External Client Apps support only modern OAuth flows (no username-password flow). It also says SOAP login() is disabled by default in new orgs, and the call in API versions 31.0 through 64.0 is no longer supported from Summer ’27. Plan any SOAP-login integration’s move to OAuth now.

Which flow fits the integration user depends on who runs the integration:

MFA rules for API logins

Salesforce requires MFA for direct UI logins by internal users, but Salesforce Help says it doesn’t require MFA for integration login types via the API. You can add a second challenge with the Multi-Factor Authentication for API Logins permission, but most server-to-server flows can’t answer one, so it rarely fits a true integration user.

Two consequences. First, the API-only license is what keeps an integration user out of the MFA problem: it never logs in to the UI, so it never meets the UI MFA prompt. Second, because there is no second factor, your controls are the OAuth app, login IP ranges, short-lived tokens and monitoring.

Note also that the old Waive Multi-Factor Authentication for Exempt Users permission no longer exempts users automatically once MFA is enforced in your org; restoring that exemption for valid cases goes through Salesforce Customer Support.

Monitoring integration users

A dedicated user per integration makes monitoring easy, because every log line already says which system it was.

• Login History. In Setup, Login History shows up to 20,000 logins from the past six months, with download for more. Filter or build a list view on your integration users and watch for logins from unexpected IPs, failed attempts and sudden changes in volume.
• API Total Usage event logs. The API Total Usage event type records REST, SOAP and Bulk API requests with the user, the connected app and whether the call counted against your API limit. According to Salesforce, every org gets the past 24 hours of it at no extra cost; if you license Event Monitoring (on its own or as part of Shield), you get 30 days, extendable up to a year. It is the quickest way to see which integration is eating your daily API allocation; without Event Monitoring, download it daily if you want history.
• Setup Audit Trail. Watch for changes to integration profiles, permission sets and OAuth apps. A permission added “just to test” is how least privilege erodes.
• Data checks. Report on records created or modified by each integration user per day. A spike usually means a loop or a bad batch, not real growth.

Review every integration user at least twice a year: is the integration still in use, does its owner still work here, are its permissions still the minimum, and when was its secret last rotated. Deactivate users of retired tools; they are standing access nobody watches.

Pitfalls and how to fix them

The last row is a bonus of dedicated users: because each integration has its own user, flows and triggers can tell “changed by the ERP” from “changed by a person” and skip echo updates. The Salesforce integration patterns guide covers loop-safe designs in more depth.

When the integration itself needs building

Setting up the user is an afternoon. The integration behind it is the bigger job, and that is where most of the cost sits.

Building your own connection on the REST, Bulk or Pub/Sub APIs? Our Salesforce API integration guide walks through API choice, limits, error handling and the server-to-server setup. If several systems need to feed Salesforce, the Salesforce integration guide compares native connectors, iPaaS (integration platform as a service) tools and custom builds, and teams on MuleSoft can read the Salesforce MuleSoft integration guide.

Add-on Integration user licenses are a separate, usually small line on top of these figures: get the quote from your Salesforce account executive. The build ranges themselves, and what moves a project within them, are in our API integration cost guide.

Integration user checklist

Go through it once per integration user, not once for the whole org: a single shared admin login can hide behind an otherwise good score.

FAQ

Where Gilzor fits

Cleaning up integration users often turns up integrations that need rebuilding, not just new credentials. Gilzor, a software development company with engineers in Poland and Cyprus and not a Salesforce reseller, can audit what connects to your org, move each system to a least-privilege integration user and External Client App, and build or rebuild the integrations behind them with support after launch. How that work is scoped is on our Salesforce integration services page.