forcedotcom/sf-skills

integration-connectivity-connected-app-configure

Salesforce Connected Apps and External Client Apps OAuth configuration with 120-point scoring.

View source
Original skill document

Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.

integration-connectivity-connected-app-configure: Salesforce Connected Apps & External Client Apps

Use this skill when the user needs OAuth app configuration in Salesforce: Connected Apps, External Client Apps (ECAs), JWT bearer setup, PKCE decisions, scope design, or migration from older Connected App patterns to newer ECA patterns.

Scope

In scope:

  • .connectedApp-meta.xml or .eca-meta.xml files
  • OAuth flow selection and callback / scope setup
  • JWT bearer auth, device flow, client credentials, or auth-code decisions
  • Connected App vs External Client App architecture choices
  • Consumer key / secret / certificate handling strategy

Out of scope — delegate elsewhere:


First Decision: Connected App or External Client App

If the need is...Prefer
simple single-org OAuth appConnected App
new development with better secret handlingExternal Client App
multi-org / packaging / stronger operational controlsExternal Client App
straightforward legacy compatibilityConnected App

Default guidance:

  • Choose ECA for new regulated, packageable, or automation-heavy solutions.
  • Choose Connected App when simplicity and legacy compatibility matter more.
  • Spring '26 note: creation of new Connected Apps is disabled by default in orgs. For new integrations, prefer External Client Apps unless Connected App compatibility is explicitly required.

Required Inputs

Ask for or infer:

  • App type: Connected App or ECA
  • OAuth flow: auth code, PKCE, JWT bearer, device, client credentials
  • Client type: confidential vs public
  • Callback URLs / redirect surfaces
  • Required scopes
  • Distribution model: local org only vs packageable / multi-org
  • Whether certificates or secret rotation are required

Workflow

1. Choose the app model

Decide whether a Connected App or ECA is the better long-term fit using the decision table above.

2. Choose the OAuth flow

Use caseDefault flow
backend web appAuthorization Code
SPA / mobile / public clientAuthorization Code + PKCE
server-to-server / CI/CDJWT Bearer
device / CLI authDevice Flow
service account style appClient Credentials (typically ECA)

3. Start from the right template

Read the appropriate template before generating — do not build from scratch:

TemplateUse case
assets/connected-app-basic.xmlSimple API integration, minimal OAuth
assets/connected-app-oauth.xmlWeb app with full OAuth 2.0 configuration
assets/connected-app-jwt.xmlJWT bearer / server-to-server
assets/connected-app-canvas.xmlEmbedding external apps in Salesforce UI (Canvas)
assets/external-client-app.xmlECA header file — all new ECA builds start here
assets/eca-global-oauth.xmlECA global OAuth settings (scopes, PKCE, rotation)
assets/eca-oauth-settings.xmlECA per-app OAuth settings
assets/eca-policies.xmlECA configurable policies

If you need source-controlled ECA OAuth security metadata, retrieve it from an org first and treat the retrieved file as the schema source of truth:

sh
sf project retrieve start --metadata ExtlClntAppOauthSecuritySettings:<AppName> --target-org <alias>

4. Apply security hardening

Read references/security-checklist.md for the full 120-point security checklist. Favor:

  • Least-privilege scopes
  • Explicit callback URLs
  • PKCE for public clients
  • Certificate-based auth where appropriate
  • Rotation-ready secret / key handling
  • IP restrictions when realistic and maintainable

5. Validate deployment readiness

Read references/testing-validation-guide.md before handoff. Confirm:

  • Metadata file naming is correct (see Gotchas below)
  • Scopes are justified
  • Callback and auth model match the real client type
  • Secrets are not embedded in source

6. Handle errors

If deployment fails, check the error output for:

  • DUPLICATE_VALUE — a Connected App or ECA with this name already exists; rename or retrieve-then-update instead
  • INVALID_CROSS_REFERENCE_KEY — the externalClientApplication name in an ECA settings file doesn't match the .eca-meta.xml filename exactly
  • INSUFFICIENT_ACCESS_OR_READONLY — user lacks the "Manage Connected Apps" permission
  • If any step fails, do not proceed to the next step — surface the error to the user with the specific message above

Rules / Constraints

RuleRationale
Never commit consumer secrets to source controlCredential exposure risk
Never use Full scope by defaultUnnecessary privilege; request only what the app needs
Always use PKCE for public clients (mobile, SPA)Prevents auth code interception
Never use wildcard or overly broad callback URLsToken interception risk
ECA OAuth security settings must be retrieved from org before editingFile schema is not fully documented; retrieve-first ensures accuracy
Use <alias> placeholders in CLI commands, never hardcoded org URLsOrg URLs vary per environment
Detect actual packageDirectory from sfdx-project.json before writing filesProjects may not use the default force-app/main/default/ layout

Metadata Notes That Matter

Connected App

Default source location (verify via sfdx-project.json → packageDirectories):

  • <packageDir>/connectedApps/

External Client App

ECA metadata spans multiple top-level source directories. Default locations (verify via sfdx-project.json):

DirectoryMetadata typeFile suffix
<packageDir>/externalClientApps/ExternalClientApplication.eca-meta.xml
<packageDir>/extlClntAppGlobalOauthSets/ExtlClntAppGlobalOauthSettings.ecaGlblOauth-meta.xml
<packageDir>/extlClntAppOauthSettings/ExtlClntAppOauthSettings.ecaOauth-meta.xml
<packageDir>/extlClntAppOauthSecuritySettings/ExtlClntAppOauthSecuritySettings.ecaOauthSecurity-meta.xml
<packageDir>/extlClntAppOauthPolicies/ExtlClntAppOauthConfigurablePolicies.ecaOauthPlcy-meta.xml
<packageDir>/extlClntAppPolicies/ExtlClntAppConfigurablePolicies.ecaPlcy-meta.xml

Gotchas

GotchaDetail
.ecaGlblOauth not .ecaGlobalOauthThe global OAuth suffix is abbreviated — using the long form will break deployment
.ecaPlcy not .ecaPolicySame abbreviation pattern — the general policy suffix is short form
.ecaOauthSecurity for security settingsUse .ecaOauthSecurity, not .ecaSecurity
ECA OAuth security settings are retrieve-onlyCannot be created from scratch in source — always retrieve from org first
Spring '26: new Connected Apps disabled by defaultNew orgs block Connected App creation; use ECA unless explicitly required
Consumer key is generated post-deployYou cannot set the consumer key in metadata — retrieve it after first deployment

Output Expectations

When finishing, confirm and report in this order:

  1. App type chosen — Connected App or External Client App
  2. OAuth flow chosen
  3. Files created or updated — list each metadata file path
  4. Security decisions — scopes, PKCE, certs, secrets, IP policy
  5. Next deployment / testing step

Suggested output shape:

text
App: <name>
Type: Connected App | External Client App
Flow: <oauth flow>
Files: <paths>
Security: <scopes, PKCE, certs, secrets, IP policy>
Next step: <deploy, retrieve consumer key, or test auth flow>
Score: <x>/120

Cross-Skill Integration

NeedDelegate toReason
Named Credential / callout runtime configintegration-connectivity-generateruntime integration setup
Deploy app metadataplatform-metadata-deployorg validation and deployment
Apex token or refresh handlingplatform-apex-generateimplementation logic

Score Guide

ScoreMeaning
80+production-ready OAuth app config
54–79workable but needs hardening review
< 54block deployment until fixed

Reference File Index

FileWhen to read
assets/connected-app-basic.xmlStep 3 — template for simple Connected App with minimal OAuth
assets/connected-app-oauth.xmlStep 3 — template for full OAuth 2.0 Connected App
assets/connected-app-jwt.xmlStep 3 — template for JWT bearer / server-to-server Connected App
assets/connected-app-canvas.xmlStep 3 — template for Canvas app embedding in Salesforce UI
assets/external-client-app.xmlStep 3 — ECA header file template
assets/eca-global-oauth.xmlStep 3 — ECA global OAuth settings template (PKCE, rotation, callbacks)
assets/eca-oauth-settings.xmlStep 3 — ECA per-app OAuth settings template
assets/eca-policies.xmlStep 3 — ECA configurable policies template
references/oauth-flows-reference.mdStep 2 — detailed OAuth flow comparison and decision guide
references/security-checklist.mdStep 4 — full 120-point security scoring checklist
references/testing-validation-guide.mdStep 5 — pre-deployment validation and testing guide
references/migration-guide.mdWhen migrating from Connected App to ECA patterns
references/example-usage.mdFull end-to-end examples for common OAuth scenarios
from this repository

More skills

All skills
forcedotcom
Community

design-systems-slds-apply

Apply SLDS-compliant UI using the correct blueprints, styling hooks, utility classes, and icons. Use when building any UI that needs SLDS, choosing between Lightning Base Components and SLDS Blueprints, applying styling hooks for theming, using utility classes for layout and spacing, or selecting icons. Triggers include \"build a modal\", \"create a form\", \"data table\", \"SLDS styling\", \"style with hooks\", \"add an icon\".

installs
5
GitHub stars
948
Updated
28 de ago.
forcedotcom
Community

design-systems-slds-validate

Audit Lightning Web Components for SLDS design-system compliance and produce a scored quality report. Runs the SLDS linter and analyzes CSS for theming hook usage and pairing, scoring SLDS findings across categories into an overall grade. Use when asked to \"score my component's SLDS\", \"SLDS scorecard\", \"SLDS quality report\", \"audit SLDS compliance\", \"how good is my SLDS\", \"check SLDS quality\", \"rate my SLDS styling\", \"evaluate my component's SLDS\", \"is this component's SLDS ready to ship?\", \"look at my LWC for SLDS issues\", \"audit SLDS before I submit\", \"review my component's SLDS before code review\", or any time a user wants an SLDS quality assessment or SLDS production-readiness check on an LWC. Not for fixing violations (use design-systems-slds2-migrate), building new components (use design-systems-slds-apply), or accessibility/WCAG/ARIA audits (use experience-accessibility-validate).

installs
5
GitHub stars
948
Updated
28 de ago.
forcedotcom
Community

design-systems-slds2-migrate

Migrate Lightning Web Components from SLDS 1 to SLDS 2 by running the SLDS linter and fixing violations. Use this skill whenever users mention SLDS 2, SLDS uplift, linter violations, LWC token migration, class overrides, hardcoded CSS values that need SLDS hook replacement, or styling hook selection. Covers all styling hook categories — color, spacing, sizing, typography, borders, radius, and shadows. Also use when users mention no-hardcoded-values, no-slds-class-overrides, lwc-to-slds-hooks, no-deprecated-tokens-slds1, or ask about SLDS component migration — even if they don't explicitly say \"uplift\" or \"migration\".

installs
5
GitHub stars
948
Updated
28 de ago.
forcedotcom
Community

agentforce-architecture-analyze

Declared architecture snapshot for one Agentforce agent: planner, topics, actions, flows, Apex, prompt templates, and NGA plugins. Renders a human-readable architecture document and Mermaid invocation graph from design-time metadata (not runtime audit rows). TRIGGER when user asks to describe, diagram, inventory, audit, document, or diff (e.g. v3 vs v5) the architecture / action tree / topic structure / tool inventory of a specific agent by agent API name in a specific org. DO NOT TRIGGER for runtime session traces, conversation transcripts, generation timings, or gateway audit chains — this skill reads design-time metadata only (use agentforce-d360-analyze for session traces).

installs
4
GitHub stars
948
Updated
28 de ago.