Give each Salesforce integration its own user

Shared Salesforce integration users blur audit trails, widen permissions, and slow support. Use one integration user per system before cleanup gets harder.

A shared Salesforce integration user looks efficient until something breaks. Then every API update, failed login, and field overwrite points back to the same generic account.

For a mid-market org with telephony, external intake, marketing automation, compliance checks, data enrichment, and finance systems, that becomes a support problem. It also becomes an audit problem.

The better pattern is direct: give each material integration its own Salesforce user, permission set, connected app, and monitoring plan.

What is a Salesforce integration user?

An integration user is a Salesforce user account created for a system, not a person. That system may need to read data, write data, authenticate through OAuth, or run scheduled syncs.

Common examples include:

• A telephony platform writing call records to Task
• An external portal creating Case records
• A marketing tool syncing Lead and Contact
• A finance system updating billing fields on Account
• A compliance vendor checking consent or do-not-call status
• A data warehouse extracting Opportunity, Case, or custom object data

The common mistake is putting several of these systems behind one account named integration@company.com, apiuser@company.com, or sfconnector@company.com.

That setup may work during implementation. The API calls succeed. The data moves. Nobody has to request another license. The design cost shows up later.

When five systems share one Salesforce user, admins lose clean answers to basic questions:

• Which system changed Contact.Phone?
• Which system created this duplicate Lead?
• Which system updated Case.Status?
• Which system is using the most API calls?
• Which system needs access to CaseComment?
• Which vendor token should be revoked after contract end?
• Which integration failed authentication last night?

Salesforce gives you audit tools, but those tools depend on identity. CreatedById, LastModifiedById, Login History, Setup Audit Trail, connected app usage, and event logs are clearer when each system has its own user.

If the identity is shared, the evidence is blurred.

Use one integration user per system

The practical rule is simple: one external system, one Salesforce integration user.

That does not mean one user per endpoint, workflow, or scheduled job. It means each vendor platform or owned application gets a distinct identity.

A reasonable user list might look like this:

• int_talkdesk@company.com
• int_retool_portal@company.com
• int_dnc@company.com
• int_handwrytten@company.com
• int_data_warehouse@company.com

Use names your admin team can read in record history. Avoid vague labels like apiuser, sfconnector, or automation.

Each integration user should have:

• A clear internal owner
• A connected app, where OAuth is used
• A dedicated permission set or permission set group
• A documented object and field scope
• A documented authentication method
• A support contact
• A vendor offboarding plan
• Monitoring expectations for login failures and API usage

Salesforce supports this pattern directly through the Salesforce Integration user license. Assigning it provisions the Minimum Access – API Only Integrations profile and makes the Salesforce API Integration permission set license available for assignment. On that license, API Enabled and API Only are both set to TRUE and cannot be edited, so the user can authenticate through REST, SOAP, or Bulk API but never log into the UI.

The free allotment is where the math gets real. Enterprise, Unlimited, and Performance Edition orgs are provisioned with five Salesforce Integration user licenses at no additional cost. Developer Edition orgs get one. Additional licenses require a conversation with your account executive.

Five is the number to watch. The mid-market org described at the top — telephony, external intake, marketing automation, compliance, data enrichment, finance — is already at six material systems. One-user-per-system exhausts the free pool before onboarding is finished. At that point you have three choices: buy more Integration licenses, consume full user licenses for the overflow (more expensive, and those users can log into the UI), or consolidate the lowest-risk systems behind a shared account on purpose. Pick deliberately. Do not let the sixth integration make the decision by default.

Two caveats before you plan around the license. First, not every vendor's integration works on it. Some managed-package permission sets will not assign to an Integration user, and a few connectors — HubSpot's, for one — still require a full user license. Confirm with the vendor before you commit. Second, the profile naming shifted: Spring '24 replaced the older "API Only Systems Integrations" profile with "Minimum Access – API Only Integrations," but only in newly created orgs. Existing orgs keep the old profile, so what you see in Setup depends on when the org was provisioned.

The architecture point still holds. The license decision should follow the identity model, not replace it. If licensing forces a shared account, make it intentional, temporary, and reviewed on a set cadence — not the accident it usually becomes.

Keep Salesforce integration permissions narrow

Integration users should not be system administrators by default.

That is the second common mistake. A vendor asks for broad access during setup. An admin grants the System Administrator profile to keep the project moving. The project ends, but the permission stays.

That creates risk. It also makes troubleshooting harder because the integration may start touching objects or fields outside its purpose.

Start with the objects and fields the system actually needs.

A telephony integration may need:

• Read access to Lead, Contact, and Account
• Create access to Task
• Update access to specific phone fields, if the tool normalizes numbers
• Access to call disposition fields
• No access to Opportunity.Amount
• No access to finance, HR, or payroll objects

An external intake portal may need:

• Create access to Case
• Read access to routing reference data
• Create access to related custom intake objects
• No delete access
• No broad access to existing customer records unless matching is required

A compliance or consent service may need:

• Read access to Lead and Contact
• Update access to consent fields such as Do_Not_Call__c
• Read access to campaign or source fields, if rules depend on them
• No access to unrelated case history

The permission set name should say what it does. Talkdesk integration access is better than API access full.

Field-level security matters. If the integration only updates Do_Not_Call__c, it should not have edit access to every field on Contact.

Also review profile settings. API-only users should not have interactive access unless there is a documented reason. If the integration uses OAuth, review the connected app before production. Check permitted users, token policy, IP restrictions, and refresh token behavior.

Track API usage and integration failures

Separate integration users do not create separate org-wide API limits. Salesforce API limits are still enforced at the org level. The exact limit depends on edition, licenses, and contract terms.

Separate users do make usage easier to understand.

If a data enrichment tool consumes a large share of API calls, you want to see that clearly. If an external portal starts retrying failed Case inserts every minute, you want to isolate that traffic. If a vendor changes polling frequency, you want the evidence tied to that vendor's user or connected app.

For each integration, document:

• Direction: inbound to Salesforce, outbound from Salesforce, or both
• Frequency: real-time, scheduled, event-based, or manual
• Objects touched
• Expected daily API volume, if known
• Peak periods, such as month-end or open enrollment
• Retry behavior
• Error owner
• Alert location

Do not skip retry behavior. Many integration incidents are not caused by one failed request. They are caused by repeated failed requests.

A bad token, validation rule change, required field update, or duplicate rule can turn into thousands of failed calls if the external system retries aggressively.

Salesforce validation rules and flows also need to account for integration users. Sometimes an integration should bypass a user-facing validation rule. Sometimes it should not. The answer depends on the process.

If you add bypass logic, make it explicit. Avoid hidden exceptions tied to a username. Prefer a custom permission assigned to the integration user's permission set. Reference that custom permission in validation rules or flows.

That makes the exception easier to audit. It also moves more safely between sandboxes and production.

Migrate shared integration users in stages

If your org already uses one shared integration account, do not unwind it all at once.

Start with an inventory:

• Review connected apps
• Review named credentials and external credentials
• Review installed packages with API access
• Check Login History for source patterns
• Check record history on high-volume objects
• Ask vendors which Salesforce username they use
• Review middleware connections, such as MuleSoft, Boomi, Workato, Zapier, or custom scripts

Then separate the highest-risk systems first.

Good candidates include:

• Systems that update customer identity fields
• Systems that create or update Case
• Systems that touch consent or communication preferences
• Systems with high API volume
• Systems managed by outside vendors
• Systems scheduled for contract renewal or replacement

For each migration, create the new user in a sandbox first. Assign the narrow permission set. Update the connected app, named credential, middleware connection, or vendor credentials. Test the main record paths.

Confirm that CreatedById and LastModifiedById show the new user where expected. Then move the same change to production.

After cutover, reduce the old shared user's access gradually. Do not deactivate it before confirming all integrations have moved. Watch Login History, connected app usage, and API activity for stragglers.

The documentation does not need to be long. It does need to be complete.

At minimum, keep a register with:

• Integration user
• Vendor or system name
• Internal owner
• Objects touched
• Authentication method
• Connected app
• Permission set or permission set group
• Expected API pattern
• Support contact
• Offboarding steps

Salesforce integration user checklist

Use this checklist this week:

1. List every system that reads or writes Salesforce data.
2. Match each system to the Salesforce username it uses.
3. Flag any user shared by more than one system.
4. Identify which shared user touches Lead, Contact, Case, Opportunity, or consent fields.
5. Count your material integrations against your free Integration user licenses, and decide where overflow goes.
6. Create one sandbox integration user for the highest-risk system.
7. Assign a narrow permission set.
8. Test the main create and update paths.
9. Confirm record history shows the new user.
10. Document owner, objects, auth method, connected app, and support contact.
11. Plan the production cutover.

If an integration can change Salesforce data, it deserves its own identity. Start with the shared account that touches the most sensitive records, then separate one system at a time.