Salesforce Named vs. External Credentials: The Ultimate Guide

💬 In plain words: The modern Salesforce architecture splits Named Credentials into two distinct parts. The External Credential acts as the recipe, holding the authentication method (protocol, principals) and defining who can use it via Permission Sets. The Named Credential acts as the address, holding the URL and pointing back to the External Credential. Rotation, secrets, and user access all live safely in configuration, never in your Apex code.

📌 Real-Life Example: Imagine you are integrating with a third-party ERP system. You create one External Credential named ERP_OAuth that handles the client-credentials handshake. Then, you create two separate Named Credentials—one pointing to erp.com/orders and another pointing to erp.com/invoices. Both reuse the exact same ERP_OAuth External Credential. Finally, only Salesforce users assigned the "ERP Integration" Permission Set are allowed to fire those callouts.

🧩 The Core Concept: Splitting Auth and Endpoint

Named Credentials exist to completely externalize both endpoints and authentication. This means your Apex code simply references a placeholder like callout:MyNamedCred/path and contains zero hardcoded secrets or URLs.

• The Modern Model: The legacy monolithic Named Credential has been split in two to separate the "how" from the "where."
• External Credentials (The How & Who): This defines the authentication protocol (OAuth 2.0, JWT, AWS Signature v4, Basic, or Custom Headers) and the principal identity.
• Named Credentials (The Where): This defines the actual callout URL and references the External Credential to handle the handshake.
• Automated Management: The Salesforce platform automatically injects the necessary authentication headers into your HTTP requests and refreshes OAuth tokens behind the scenes.
• Permission-Driven: Access to an External Credential's principal is strictly granted through Permission Sets.

🧠 Core Takeaway: External Credential = HOW + WHO (auth + principal). Named Credential = WHERE (URL). Code says callout:Name — never a raw URL or secret.

✨ Key Points to Remember

• Eliminates Anti-Patterns: Replaces hardcoded endpoints that break during sandbox refreshes, eliminates secrets stored in Custom Settings, and removes the need to write custom token refresh logic in Apex.
• Reusable Auth: A single External Credential can be leveraged by dozens of different Named Credentials.
• Security First: Allows for seamless secret rotation. Updating a credential in one place automatically applies it across all environments safely.

🧭 The 360 Card Summary

Rule: The External Credential holds "how" and "who". The Named Credential holds "where". Code contains neither a URL nor a secret.

Gain: You can rotate a secret in one place, and every integration environment immediately follows suit without code deployments.

Price: Introduces an extra layer of configuration. You must map principals to Permission Sets before any integration will work.

Limits: Using a Named Principal makes the entire Salesforce app act as one single identity in the remote system, which is bad for per-user auditing. Per-User Principals require each individual person to authorize once.

At Volume: Certificates and tokens require strict owners and calendar rotation dates. If an expiry is missed, your integrations will crash at 2 a.m.

⚠ INTERVIEW TRAP: Be careful when using a Named Principal! A Named Principal makes every single Salesforce user act as one master identity in the remote system. This silently bypasses the remote system's internal access model. If the remote system expects per-user permissions, you must use a Per-User Principal.

💬 Core Q&A & Interview Prep

Q: Why are Named Credentials the standard for callouts, and what exactly do External Credentials add?

🎯 Say this first: "They move URLs, authentication, and secrets completely out of code and into configuration. The new External Credentials specifically add a reusable authentication recipe where access is strictly controlled by Permission Sets."

Named Credentials remove endpoints and secrets from your Apex code. Because your callout references callout:Name, the exact same code can run safely in every Sandbox and in Production. The platform automatically injects the auth headers and manages the OAuth token refresh lifecycle.

External Credentials add a clean separation of concerns. They hold the authentication protocol and the principal. This means they are reusable across multiple Named Credentials pointing to different paths of the same API. Most importantly, access to the External Credential's principal is governed by Permission Sets, allowing you to tightly control which users can invoke a callout.

// 1. Build the request. Note: No URL and no secret in the code.
HttpRequest req = new HttpRequest();

// 2. The platform swaps in the real URL and adds the credentials.
req.setEndpoint('callout:ERP_API/v1/orders/' + orderId);
req.setMethod('GET');

// 3. Send the request
HttpResponse res = new Http().send(req);

Q: How should you design the security of the integration layer itself?

🎯 Say this first: "Use least-privilege identities, modern authentication flows, and ensure every integration traces back to exactly one dedicated credential."

Each connecting system should get its own API-only Salesforce Integration User license. It is cost-effective and inherently secure because it cannot log into the standard Salesforce UI. Assign it a Permission Set granting only the specific objects and fields it needs.

For authentication, strictly use OAuth 2.0 (like JWT bearer or client credentials) configured through an External Client App. This allows you to enforce real security policies like IP restrictions, token lifetimes, and admin pre-approvals. Never use shared logins or legacy password-plus-security-token setups.

Q: Should we use Connected Apps or External Client Apps today?

External Client Apps are the modern successor. They are fully packageable, API-first, utilize the same robust OAuth flows, and feature tighter default security settings. In fact, new Salesforce orgs now start with classic Connected Apps disabled by default. For any new build, use External Client Apps, while leaving existing Connected Apps to migrate over time.

🔗 Follow-Up Questions

Q1: When do you choose a Per-User vs. Named Principal, and where does the wrong choice become a compliance problem?

A Named Principal means Salesforce acts as a single identity for everyone. This is perfect for system-to-system syncing (like an inventory feed). Per-User means each user authenticates as themselves, which is mandatory when the external system enforces its own per-user permissions (like a document management system where User A shouldn't see User B's files). The compliance trap? Using a Named Principal against a system that has per-user access controls creates a massive audit finding. Always ask: "Whose authorization must the remote system see?"

Q2: You migrated from hardcoded endpoints in Custom Settings to Named Credentials. What improves at credential-rotation time?

Before Named Credentials, rotating a secret meant modifying configurations in every environment and hoping a developer didn't hardcode it somewhere. With the modern architecture, you rotate the secret in one place: the External Credential. Because the platform handles the OAuth/JWT token refresh automatically, a rotation is often as simple as uploading a new certificate with a brief overlap window, resulting in zero downtime. It makes rotatability a core design property rather than a dangerous retrofit.

Q3: How do External Credentials handle custom authentication scenarios, like AWS Signature v4?

If you are connecting to AWS services (like S3 or EventBridge), External Credentials natively support the AWS Signature Version 4 protocol. Instead of writing complex, custom Apex cryptography to generate AWS headers, you simply select AWS Sig4 in the External Credential, input the AWS region and service name, and provide the IAM access keys. The Salesforce platform natively hashes the payload and signs the request for you at runtime, saving hundreds of lines of fragile code.