Sf Connected Apps
Configure Salesforce Connected Apps or External Client Apps with scored OAuth flows, scopes, and metadata XML when building secure Salesforce integrations.
Overview
sf-connected-apps is an agent skill for the Build phase that configures Salesforce Connected Apps and External Client Apps with OAuth flow selection and 120-point configuration scoring.
Install
npx skills add https://github.com/jaganpro/sf-skills --skill sf-connected-appsWhat is this skill?
- 120-point scoring across 6 categories for Connected App / ECA quality
- Owns .connectedApp-meta.xml and .eca-meta.xml OAuth configuration
- Flow selection: auth code, JWT bearer, device, client credentials, PKCE decisions
- Connected App vs External Client App architecture and migration guidance
- Clear delegation: Named Credentials callouts → sf-integration; permissions → sf-permissions; Apex APIs → sf-apex
- Skill metadata version 1.1.0
Adoption & trust: 1.2k installs on skills.sh; 418 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are editing Salesforce Connected App metadata but unsure which OAuth flow, scopes, or ECA migration path is safe for your integration.
Who is it for?
Teams adding a Salesforce integration that starts with registering the client app, JWT or PKCE setup, and XML metadata in source control.
Skip if: Named Credential callout wiring, permission-set assignment reviews, or raw Apex REST implementation—those sibling sf-skills own those tasks per the skill gates.
When should I use this skill?
User configures OAuth flows, JWT bearer auth, Connected Apps, or edits .connectedApp-meta.xml / .eca-meta.xml—not Named Credentials-only callouts or Apex API code.
What do I get? / Deliverables
You produce scored, scope-aware Connected App or ECA configuration and know to hand off runtime callouts to sf-integration and policy work to sf-permissions.
- Scored Connected App or ECA configuration review
- OAuth flow and scope recommendation
- Updated .connectedApp-meta.xml or .eca-meta.xml guidance
Recommended Skills
Journey fit
OAuth app registration and .connectedApp-meta.xml work happens while wiring product integrations into Salesforce, which Prism shelves under Build. Integrations subphase fits Named Credential adjacency, JWT bearer, PKCE, and client app metadata—the connective tissue between your app and Salesforce APIs.
How it compares
Salesforce OAuth app package skill—not a generic REST API generator and not the Named Credentials runtime integration skill.
Common Questions / FAQ
Who is sf-connected-apps for?
Developers and indie SaaS builders implementing Salesforce login or API access who need Connected App or External Client App metadata and OAuth flow decisions with a structured quality score.
When should I use sf-connected-apps?
Use during Build when you touch .connectedApp-meta.xml or .eca-meta.xml, choose auth-code vs JWT bearer vs client credentials, or plan PKCE and scope design—not when you only configure Named Credentials for outbound callouts.
Is sf-connected-apps safe to install?
It may use shell and file tools to inspect Salesforce metadata; review the Security Audits panel on this Prism page and treat consumer secrets and certificates as sensitive in your repo.
Workflow Chain
Then invoke: sf integration, sf permissions
SKILL.md
READMESKILL.md - Sf Connected Apps
# sf-connected-apps: 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. ## When This Skill Owns the Task Use `sf-connected-apps` when the work involves: - `.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 Delegate elsewhere when the user is: - configuring Named Credentials or runtime callouts → [sf-integration](../sf-integration/SKILL.md) - analyzing access / permission policy assignments → [sf-permissions](../sf-permissions/SKILL.md) - writing Apex token-handling code → [sf-apex](../sf-apex/SKILL.md) - deploying metadata to orgs → [sf-deploy](../sf-deploy/SKILL.md) --- ## First Decision: Connected App or External Client App | If the need is... | Prefer | |---|---| | simple single-org OAuth app | Connected App | | new development with better secret handling | External Client App | | multi-org / packaging / stronger operational controls | External Client App | | straightforward legacy compatibility | Connected 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 Context to Gather First 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 --- ## Recommended Workflow ### 1. Choose the app model Decide whether a Connected App or ECA is the better long-term fit. ### 2. Choose the OAuth flow | Use case | Default flow | |---|---| | backend web app | Authorization Code | | SPA / mobile / public client | Authorization Code + PKCE | | server-to-server / CI/CD | JWT Bearer | | device / CLI auth | Device Flow | | service account style app | Client Credentials (typically ECA) | ### 3. Start from the right template Use the provided assets instead of building from scratch: - `assets/connected-app-basic.xml` - `assets/connected-app-oauth.xml` - `assets/connected-app-jwt.xml` - `assets/external-client-app.xml` - `assets/eca-global-oauth.xml` - `assets/eca-oauth-settings.xml` - `assets/eca-policies.xml` 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: - `sf project retrieve start --metadata ExtlClntAppOauthSecuritySettings:<AppName> --target-org <alias>` ### 4. Apply security hardening Favor: - least-privilege scopes - explicit callback URLs - PKCE for public clients - certificate-based auth where appropriate - rotation-ready secret / key handling - IP