Integration User

An integration user is a dedicated Salesforce identity used by systems rather than people. It should represent one business purpose and one access pattern. When multiple applications share the same user, privilege tends to accumulate and the blast radius of compromise expands quickly.

Expanded Definition

An integration user is a dedicated Salesforce identity used by systems rather than people, and in NHI security it should be treated as a service identity with a single business purpose, a bounded access pattern, and clearly owned lifecycle controls. That discipline matters because an integration user is not just a login, it is a persistent trust relationship between Salesforce and the application, workflow, or middleware that calls it. In practice, this makes it closer to a non-human identity than to a conventional employee account, even when the account is administered through the CRM platform. NHI Management Group recommends applying least privilege, unique ownership, and separate identities per integration path, which aligns with broader guidance in the NIST Cybersecurity Framework 2.0 and the governance model described in Ultimate Guide to NHIs. Definitions vary across vendors when a platform account is shared by multiple jobs, but the security principle stays the same: one identity should map to one purpose. The most common misapplication is reusing a single integration user for multiple applications, which occurs when teams optimise convenience over isolation and let privileges accumulate over time.

Examples and Use Cases

Implementing integration users rigorously often introduces administrative overhead, requiring organisations to weigh cleaner accountability and smaller blast radius against the cost of managing more identities.

• A Salesforce-to-ERP sync uses one integration user for order creation and a second for invoice updates, so each automation can be revoked without breaking unrelated workflows.
• An iPaaS job authenticates with a dedicated integration user whose permissions are limited to the exact objects and API calls needed for that pipeline, consistent with least-privilege expectations in the Ultimate Guide to NHIs.
• A partner portal integration uses a separate identity from internal batch jobs, reducing the chance that one third-party failure exposes every downstream process.
• A scheduled data-quality task is assigned its own integration user so logs, alerts, and permission reviews can be traced to a single business function instead of a shared account.
• When a team needs a design reference for access governance, the NIST Cybersecurity Framework 2.0 provides a useful control-oriented lens for access review and identity management.

Why It Matters in NHI Security

Integration users become high-value attack paths when they are overprivileged, shared, or left in place after the original workflow changes. NHI Management Group reports that 97% of NHIs carry excessive privileges, which is especially relevant to integration users because these accounts are often created to “just make it work” and then left to accumulate access. That pattern increases the blast radius of compromise, weakens segregation of duties, and makes incident response slower because no one can quickly tell which system truly owns the account. It also complicates offboarding, rotation, and logging, since one identity may be tied to several apps, teams, and business processes. The operational lesson is simple: if an integration user can reach multiple systems, compromise of that one identity can turn a local failure into an enterprise-wide event. Practitioners should also keep the full NHI lifecycle in view, including visibility, credential hygiene, and revocation discipline, as described in the Ultimate Guide to NHIs. Organisations typically encounter the true impact only after a failed audit, a suspicious API call, or a live incident, at which point the integration user becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between user compromise and SaaS integration compromise?
• When do service accounts become a higher risk than ordinary user accounts?
• How should security teams think about a compromised integration like Drift?
• When does an OAuth integration become too risky to keep?