Skip to content
SteveTechArcSteveTechArc Courses

What to Build On

Module 6 of 8 in the chapter Trust, Identity, and Integration Security, chapter 13 of the Integration Architect course. Each module stands on its own. Previous: Choosing a Flow · Next: Tokens as a Design Decision

The question this module answers: What should every integration be built on, coming in and going out, and what changes with the move off connected apps?

Two Gates

Section titled “Two Gates”

Chapter 4 showed the two gates at the admin’s level. Here’s the architect’s version in one picture.

Every way in, every way out Every way in, every way out, at Steve Trucking. Calling in: the integration layer, with its two identities from module 4, and FleetLink, with truck positions, both sign in through External Client Apps, highlighted, in Salesforce: every way in, one app per caller, with its own policies. Below it, also highlighted, named and external credentials: every way out, holding where, how, and who may use it. They call out to Redrock's status API, with OAuth client credentials, and to photo storage, with a signed request. The legend: the two gates, each one listed, owned and reviewed. Underneath: nothing comes in except through an app you approved; nothing leaves except through a credential you set up. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-INT-TW-12", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} CALLING IN SALESFORCE CALLED OUT TO The integration layer two identities (module 4) FleetLink truck positions External Client Apps every way in: one app per caller, its own policies Named and external credentials every way out: where, how, and who may use it Redrock's status API OAuth client credentials Photo storage a signed request signs in through signs in through calls calls Nothing comes in except through an app you approved; nothing leaves except through a credential you set up. HOW TO READ IT The two gates: each one listed, owned and reviewed © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Nothing comes in except through an app you approved; nothing leaves except through a credential you set up.

  • Every way in is an External Client App. Each caller has its own, with its own scopes and its own policies, signing in as its own integration user (module 4).
  • Every way out is a named credential, with an external credential behind it. No address or secret is written into a flow or a class.

If you can list both gates, you know every door the org has to other systems. That list is the landscape inventory from chapter 5, with its two most important columns.

Why External Client Apps

Section titled “Why External Client Apps”

The connected app was the Swiss army knife of Salesforce integration for years. It still works. But Salesforce has said where it’s going: “External client apps are the new generation of connected apps. They were designed to improve security and resolve the cumbersome packaging and distribution issues that affect connected apps” (New Connected Apps Can No Longer Be Created in Spring ‘26 (opens in a new tab), Salesforce Help, October 7, 2026, checked 2026-11-07).

What changes for the architect is who controls what. Chapter 4 took it apart: the settings belong to whoever builds the app and can be packaged; the policies belong to each org’s admin and never travel. So when a vendor’s app arrives inside a package, its policies, who may use it, from where and for how long, are still yours. And the secret never travels at all: a local External Client App isn’t copied into a refreshed sandbox, so each sandbox gets its own.

The Move Off Connected Apps

Section titled “The Move Off Connected Apps”

The move has four dates, and they’re worth putting on the integration calendar.

From connected apps to External Client Apps From connected apps to External Client Apps: four dates, numbered, with what each means beside it. 1, Spring '26, no new connected apps without a request to Support: build every new integration on an External Client App. 2, Winter '27, the migration release update, Migrate to External Client App in App Manager: a local app migrates with its consumer key and secret, so callers keep working. 3, 20 February 2027, two flows retire, username-password and user-agent: move those apps to a current flow first, because an External Client App can't use the password flow. 4, highlighted, Summer '27, end of support, enforced for production: connected apps still run, but get no fixes or support, so every app should be across by then. Underneath: packaged apps move when their vendor ships an External Client App version; ask each vendor for its date. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-INT-TW-13", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "flow/sequence 0.1.0", "theme": "stevetecharc 1.4.0"} Spring '26: no new connected apps without a request to Support Build every new integration on an External Client App. Winter '27: the migration release update Migrate to External Client App, in App Manager A local app migrates with its consumer key and secret, so callers keep working. 20 February 2027: two flows retire username-password and user-agent Move those apps to a current flow first: an External Client App can't use the password flow. Summer '27: end of support enforced for production Connected apps still run, but get no fixes or support. Every app should be across by then. 1 2 3 4 WHAT IT MEANS FOR YOU Packaged apps move when their vendor ships an External Client App version. Ask each vendor for its date. HOW TO READ IT 1 the order a step the step that matters most what comes next © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Four dates; the last one is the deadline.

  1. Spring ‘26: no new connected apps. Creating one is “prevented through both API and UI, with the exception of package installation,” unless you ask Support. “All existing connected apps will continue to work.”
  2. Winter ‘27: the migration release update. In App Manager, Migrate to External Client App creates the replacement, and “Migration preserves your consumer key and secret, so existing integrations continue to work” (Connected App to External Client App Migration (opens in a new tab), Salesforce Help, checked 2026-11-07).
  3. February 20, 2027: two flows retire, username-password and user-agent (module 1).
  4. Summer ‘27: end of support. “Connected apps will keep working, but Salesforce will no longer fix bugs or provide support for the integrations and authorization flows that use them.” The release update “is enforced for production instances in Summer ‘27” (Migrate All Connected Apps to External Client Apps (opens in a new tab), Salesforce Help, checked 2026-11-07).

Two catches in the migration, both in Salesforce’s words. “External client apps don’t support username-password flow,” and “The migration process can’t detect username-password flow.” So an app still on the password flow migrates, looks fine, and stops working. Move its integration to client credentials or the web server flow first (module 5), then migrate. And the migrated app is local to your org: an app from a managed package moves when its vendor ships an External Client App version.

So the plan for every org is the one Salesforce gives: start “by inventorying your connected apps.” For each: who owns it, which flow it uses, local or packaged, and the date it moves.

Going Out: Design Choices in a Named Credential

Section titled “Going Out: Design Choices in a Named Credential”

Named credentials are a beast. They seem simple, but they have so much power. A named credential knows the address you’re calling and, through its external credential, how to sign in: Salesforce goes and authenticates, holds on to the token, and when it expires, gets a new one. Chapter 4 set one up step by step. Here are the decisions behind it.

Build on the current kind. “Legacy named credentials are deprecated and are unsupported in future releases”; the improved one, since Winter ‘23, is “extensible, customizable, and more secure” (Understand Legacy Named Credentials (opens in a new tab), Salesforce Help, checked 2026-11-07). An old org may still have the legacy kind, holding the address and the sign-in together. Moving them is the outbound half of the same clean-up.

One external credential per system you sign in to. One external credential can serve several named credentials: one way of signing in, several addresses behind it. That’s the right grouping: everything that signs in to Redrock the same way shares one, so rotating Redrock’s secret is one change.

A named principal or a per-user principal. This is the outbound version of module 4’s question: who are you, on the other system? A named principal is “the same credential or authentication configuration… shared by all users in a given org”: one service account, the usual choice for an integration. Per-user authentication “provides access control at the individual user level”: each person signs in to the other system as themselves, for when the other system has to know which person is asking (Named Credentials Glossary (opens in a new tab), Salesforce Developers, checked 2026-11-07). Either way, the principal is given to users through a permission set, so a callout only works for the people and processes you allow.

The protocol the other system offers, at its strongest. OAuth client credentials or JWT where the other side supports them; an API key in a header when that’s all it has; a password only as the last resort (chapter 4). And if the other system requires two-way TLS, the client certificate goes on the named credential, and since Winter ‘27 a named credential can trust a server certificate from a private certificate authority (chapter 12).

An owner and an end date. Every external credential holds a secret or a certificate that will expire or need rotating. Each gets an owner and a date in the inventory, the same as every certificate in chapter 12.

What You Don’t Build On

Section titled “What You Don’t Build On”

To close the module, the short list of what not to start anything new on:

  • A new connected app. An External Client App instead.
  • The username-password or user-agent flows. Client credentials, the web server flow with PKCE, or JWT bearer.
  • A legacy named credential, or a remote site setting with the secret in code. A named credential with an external credential.
  • A shared integration user. One identity per integration.

Test knowledge. Inbound integrations use External Client Apps: settings (packaged, by the developer) and policies (local, by each org’s admin); new connected apps can’t be created since Spring ‘26 without Support, and connected apps reach end of support in Summer ‘27; the migration keeps the consumer key and secret but doesn’t support the username-password flow. Outbound callouts use named credentials (the endpoint) with external credentials (the authentication protocol and principals); named principal for one shared service identity, per-user for each user’s own; principals granted through permission sets; legacy named credentials are deprecated.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • The two gates, listed: every External Client App in and every named credential out, each with its owner.
  • For every connected app: its flow, local or packaged, and the date it moves, well before Summer ‘27; and the integrations to move off the password flow first.
  • One external credential per system, a named or per-user principal for each, and who may use it.
  • The strongest protocol each other system offers, and its certificates and secrets, with their dates.
  • What new work may never start on, written into the team’s standards.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.