Designing Resilient Integration Architecture for Salesforce Spring '26

Spring '26 is not a cosmetic release. For enterprise architects managing integration layers, it introduces changes that require deliberate re-evaluation of identity architecture, OAuth patterns, and CI/CD validation pipelines. The most consequential change — the formal deprecation path for Connected Apps in favour of External Client Apps — affects every org that has built its integration estate on the classic Connected App model.

This post covers the structural decisions architects need to make before sandbox refresh and production deployment windows close. We focus on migration sequencing, identity architecture design, endpoint governance, and automated testing patterns.

The External Client App Migration

Salesforce introduced External Client Apps (ECAs) as the next-generation alternative to Connected Apps, with richer policy controls and cleaner separation of OAuth client configuration. Spring '26 strengthens the signal: starting with this release, creating new Connected Apps requires contacting Salesforce Support, and in subsequent releases that exception will be removed entirely. Existing Connected Apps remain functional, but new identity-related capabilities are being built exclusively for ECAs.

One important constraint to note upfront: External Client Apps do not support the username-password OAuth flow. If you are migrating a Connected App that currently uses username-password flow, that flow will not work on the ECA. Salesforce recommends migrating to the OAuth 2.0 web server flow with PKCE or the OAuth 2.0 client credentials flow instead.

The migration path is not a simple rename. A Connected App bundles OAuth settings, certificate references, SAML service provider config, and Canvas app settings into a single object. ECAs separate these concerns into distinct configuration surfaces. Before migrating, audit each Connected App for:

• Grant types in use — Web Server (authorization code), JWT Bearer, Client Credentials, Refresh Token. Each maps to a different ECA policy set. Confirm whether username-password flow is in use and plan the replacement pattern before migration.
• Certificate references — Review how each Connected App references its signing certificate and plan how that association will be maintained in the ECA configuration. Consult Salesforce Help documentation for ECA certificate configuration specifics.
• Callback URLs — Assess whether the registered callbacks are static or dynamically constructed. The ECA model enforces stricter redirect URI validation.
• IP restrictions and session policies — These shift to a dedicated OAuth policy configuration on the ECA. Existing org-level IP allowlists do not automatically inherit.

To inventory your Connected Apps before planning your migration window, use Setup > App Manager, which lists all Connected Apps with their configuration details. You can also query Connected App metadata via the Tooling API (the ConnectedApplication object in the Tooling API, not standard SOQL) if you need to automate the inventory process. Cross-reference against OAuth usage logs in the Event Monitoring API (event type ApiTotalUsage and ConnectedApp) to identify dormant apps that can be decommissioned rather than migrated.

OAuth and JWT Patterns for Integration Users

The JWT Bearer flow remains the recommended pattern for server-to-server integrations where no interactive user consent is possible. The signing certificate must be associated with the ECA (consult your ECA configuration for the specific mechanism), and the sub claim must resolve to an active integration user with a valid permission set that grants API access.

A compliant JWT assertion looks like this:

{
  "iss": "YOUR_ECA_CONSUMER_KEY",
  "sub": "integration.user@yourorg.com",
  "aud": "https://login.salesforce.com",
  "exp": 1743380400
}

The exp claim must not exceed 3 minutes from the current time. Clock skew between your integration server and Salesforce token endpoint is a common silent failure — instrument your token request latency and alert on values approaching 30 seconds.

For the Client Credentials flow — appropriate for machine-to-machine scenarios where you control both sides — ECAs provide per-ECA token lifetime controls. This matters for high-frequency integrations: shorter-lived tokens reduce blast radius on credential compromise, but require your token refresh logic to tolerate higher renewal rates. Design your HTTP client to treat 401 responses as a prompt to re-acquire tokens, not as a fatal error.

Certificate Lifecycle Management

Certificate expiry is the most common cause of integration outages in enterprise Salesforce orgs. Spring '26 introduces certificate expiry notifications delivered to the org's Certificate and Key Management notification recipients, but does not yet provide automated rotation. Architects must build this themselves.

Certificate management in Salesforce is handled through Setup > Certificate and Key Management. Certificates are not queryable as a standard SObject via SOQL in Apex — access to certificate metadata is available through the Tooling API or the Setup UI. For automated expiry monitoring, the recommended approach is to:

1. Use the Tooling API to retrieve certificate expiry dates from a scheduled integration job running outside Salesforce (or via a Named Credential callout to the Tooling API endpoint).
2. Write expiry dates to a custom object or custom metadata type that is queryable from Apex.
3. Schedule an Apex job that queries that custom object and triggers alerting or rotation workflows when expiry is within your warning threshold.

If you want to build a platform event-driven rotation workflow, you will need to define a custom platform event (for example, a certificate expiry alert event with fields for the certificate name and expiry date). The platform event definition is something you create in your org — Salesforce does not ship a pre-built certificate expiry platform event. Once defined, your scheduled monitoring job can publish events on that channel to trigger downstream rotation flows.

The rotation flow itself should: generate a new self-signed certificate (or fetch from your CA via a Named Credential callout), update the ECA certificate reference, and run a smoke-test callout to validate the new credential before decommissioning the old one. Never delete an expiring certificate until you have confirmed the replacement is working end-to-end.

My Domain Governance

Spring '26 enforces My Domain as a prerequisite for all new ECA deployments. Orgs that have historically relied on the legacy login.salesforce.com or instance-specific endpoints for token acquisition need to update their integration configurations to use the My Domain-based login URL.

The correct token endpoint format is:

https://[your-domain].my.salesforce.com/services/oauth2/token

For orgs with multiple sandboxes, the sandbox subdomain format follows the pattern [your-domain]--[sandbox-name].sandbox.my.salesforce.com. Hardcoding the base URL in integration configurations is an antipattern — store it as a Named Credential base URL or a custom metadata type value, scoped per environment. This is the single change that most consistently reduces deployment friction across sandbox refresh cycles.

CI/CD Validation for Integration Configurations

ECA configuration is represented as metadata and can be source-tracked and deployed via the Metadata API or SFDX. This creates the opportunity — and the obligation — to validate integration configuration in your CI pipeline before it reaches production.

A minimal validation pipeline for integration metadata should include:

• Schema validation — Assert that all required ECA fields are populated: consumer key, OAuth configuration, valid callback URIs, and certificate reference (for JWT flows).
• Environment substitution check — Verify that no production endpoint URLs or credentials have leaked into sandbox-targeted metadata. Use a pre-deploy script to scan for patterns like .my.salesforce.com in non-production branches.
• Connected App deprecation gate — Flag any new Connected App deployments in the pipeline. New integrations should not be built on the deprecated model.
• Token acquisition smoke test — Post-deploy, execute a parameterised token acquisition test using the deployed ECA's consumer key. Assert a 200 response and a valid access token structure. Fail the deployment if this test does not pass within your integration test window.

Migration Sequencing Recommendation

If you are managing a large integration estate, the migration should be sequenced by risk tier rather than alphabetically or by creation date. A practical tier model:

• Tier 1 (Migrate last) — Revenue-critical integrations: order management, billing, payment gateway connections. These require a full dry-run in a full-copy sandbox with production data volume before cutover.
• Tier 2 (Migrate second) — Operational integrations: ERP sync, HR data feeds, reporting extracts. Can be migrated in a developer sandbox with representative data.
• Tier 3 (Migrate first) — Internal tooling, monitoring integrations, low-volume administrative automations. Low blast radius, high learning value for the migration team.

Document the pre- and post-migration state for each integration: the Connected App name, the new ECA identifier, the integration user, the grant type, and the certificate alias. This table becomes your rollback reference and your audit evidence.

What To Do Now

Spring '26 is already active on production orgs. If you have not yet audited your Connected App inventory, that is the immediate priority. Use Setup > App Manager, cross-reference with Event Monitoring, and produce a tiered migration backlog before your next PI planning cycle.

For orgs without an automated certificate expiry monitoring process, implement that tooling now — not before the next renewal deadline. Certificate-related integration outages are entirely preventable with a modest engineering investment, and Spring '26's expiry notifications give you a platform-level signal to act on.

---