Most Salesforce orgs have integrations that nobody fully owns. They were built by a consultant who left, configured by an admin who no longer remembers the details, and authenticated with credentials that nobody rotates. They work, so nobody touches them.
But now Salesforce just made it a lot harder to ignore.
The integration sprawl nobody talks about
When teams evaluate their Salesforce stack, they focus on licences, features, and adoption. Integrations sit in the background doing their job until they do not. Then everyone scrambles to find the person who built it, locate the credentials, and understand what it even does.
This is common. A mid-size org running Salesforce for several years typically has dozens of active integrations. ERP connectors, marketing platforms, data enrichment tools, internal APIs, partner feeds. Each one was set up for a reason. Very few of them were set up with a clear owner, a documented auth pattern, or a rotation schedule.
Shared credentials mean a breach in one system can pivot into Salesforce. Unused integrations with live tokens are open doors. Integrations running on admin user accounts are a compliance issue waiting to surface.
Why Connected Apps became a governance headache
Connected Apps have been the standard way to give external systems access to Salesforce for years. They work. But they were built for a simpler era when integration landscapes were smaller and security expectations were lower.
The core problem with Connected Apps at scale is visibility.
They are globally available by default, meaning any external system can attempt to authenticate against your org once a Connected App exists.
Developer settings and admin policies were intertwined, making it difficult to separate who was responsible for what. And because they were easy to create, orgs ended up with a lot of them, many with broader OAuth scopes than the integration actually needed.
The result is a long list of Connected Apps in Setup, some active, some dormant, most with unclear ownership, and a few with permissions that made sense in 2019 and look alarming today.
What External Client Apps actually fix
Salesforce introduced External Client Apps as the next generation of integration framework, and the design decisions reflect real governance priorities rather than just technical modernisation.
The most important change is the default posture.
Unlike Connected Apps, an External Client App cannot be used to authenticate against an org unless it is explicitly installed or defined there. Shadow connections, where an external tool authenticates without an architect or admin ever deliberately permitting it, are no longer possible with this model.
The second significant change is role separation.
Connected Apps blurred the line between the developer who built the integration and the admin who managed it. External Client Apps formalise two distinct configuration layers. Developers define what the app is capable of. Admins in each org control when and how it is used. That separation creates clear ownership, which is what governance actually requires.
Third, External Client Apps are built for modern authentication patterns.
Older flows that embedded credentials directly are no longer supported. The model enforces explicit client identity, modern OAuth flows, and clear boundaries between authentication, authorisation, and policy enforcement.
What this means for your integration register
The shift to External Client Apps is an opportunity to build something most orgs are missing: a documented integration register. Not a spreadsheet someone made two years ago. An actual record of every system connecting to Salesforce, with the following information attached to each entry:
- System name and business purpose.
- Integration owner, both technical and business-side.
- Authentication type and OAuth flows in use.
- Scopes granted and whether they are proportionate to the function.
- Token rotation schedule and last rotation date.
- Whether credentials are shared with other integrations or systems.
- Risk classification: what data can this integration read, write, or delete.
This is not an extensive project. Most of the information already exists somewhere. The work is centralising it, assigning owners, and making it part of standard operational practice rather than a one-time audit exercise.
Building an approval flow for new integrations
One pattern that pays off quickly is a lightweight approval process for new integrations before they go live. Not a bureaucratic gate, but a structured conversation that covers the basics.
What does this integration need to access in Salesforce and why. Which authentication flow will it use. Who owns it on both the vendor side and the internal side. What is the plan when credentials need to rotate or the vendor relationship ends.
External Client Apps support this pattern well because the separation between developer configuration and admin policy means there is a natural checkpoint. The integration has to be explicitly admitted into the org. That moment is the right time to answer these questions rather than after the fact.
Token rotation and monitoring as standard practice
Credential rotation is one of those practices most teams agree with in principle and very few apply consistently. With integrations, the problem is that rotation requires coordination between Salesforce, the external system, and whoever manages that vendor relationship. It is easy to defer.
External Client Apps support automated credential rotation through the Metadata API, which removes much of the manual friction. For teams running DevOps pipelines, this means rotation can become part of standard operations rather than a quarterly reminder that gets ignored.
On the monitoring side, Setup Audit Trail logs policy and setting updates for External Client Apps. Pairing that with event monitoring on API access gives you a clearer picture of what each integration is actually doing versus what it is permitted to do. Anomalies become visible. Dormant integrations surface. Over-permissioned apps become easier to identify and fix.
Migration considerations for existing Connected Apps
Salesforce has provided a migration path from Connected Apps to External Client Apps, and the trajectory of the platform makes it clear that External Client Apps are the long-term model. That does not mean everything needs to migrate immediately.
Working integrations that are not causing governance problems do not need to be touched urgently. The higher priority is new integrations, which should default to External Client Apps. After that, the focus should be on Connected Apps with the highest risk profile: broad OAuth scopes, shared credentials, unclear ownership, or connections to systems handling sensitive data.
When migrating, the main practical consideration is sandbox behavior. Local External Client Apps are not copied to sandboxes, only packaged ones. Teams used to Connected Apps appearing automatically in cloned sandboxes need to adjust their deployment and testing processes.
What decision makers should take from this
The shift toward External Client Apps is not primarily a developer concern. It is an architecture and risk concern that decision makers should understand.
Every unowned integration in your Salesforce org is a potential access path that nobody is actively watching. Every over-permissioned Connected App is a wider blast radius if something goes wrong. Every shared credential is a single point of failure in your security posture.
External Client Apps provide the technical foundation for better governance. But the governance itself requires a decision to priorities it, assign ownership, and treat integration security as an ongoing operational responsibility rather than a setup task.
The orgs that handle this well are not the ones with the fewest integrations. They are the ones that know exactly what they have, who owns it, and what it can touch.
Integration governance is not a one-time project. It is the difference between a Salesforce org you understand and one you are managing by memory.
TrueSolv can inventory your Salesforce integrations, score them for risk, and build a migration plan to External Client Apps that avoids downtime. Contact us.
