/platform-salesforce-connect-adapter-generate

name: platform-salesforce-connect-adapter-generate
description: "Custom Apex adapter generation for Salesforce Connect — connects any external REST API to Salesforce as live, queryable External Objects without ETL or copying. TRIGGER when: connecting a non-standard external API, writing a DataSource.Provider/Connection or a `.cls`/`.cls-meta.xml` custom adapter class, adding a `.namedCredential-meta.xml` for the adapter's callout, surfacing external data as records, \"custom adapter\", \"ExternalId field\", \"DataSource namespace\", or whether custom Apex fits. DO NOT TRIGGER when: a standard adapter is already configured (OData, Snowflake), for copy/bulk-sync (use platform-data-manage), or for Apex callouts outside Connect (use platform-apex-generate or integration-connectivity-generate)."
metadata:
  version: "1.0"
  minApiVersion: "66.0"
  accessCheck: "License.SalesforceConnect"
  domains:
    - Platform
  relatedSkills:
    - integration-connectivity-generate
    - platform-apex-generate
    - platform-data-manage
  cliTools:
    - tool: ["sf"]
      semver: ">=2.0.0"

Salesforce Connect — Custom Apex Adapter

Route the user through building a complete custom Salesforce Connect Apex adapter: two Apex classes, metadata deployment, and registration. Do not guess at the user's API shape — ask before generating.

Scope

**In scope:** Generating `DataSource.Connection` and `DataSource.Provider` Apex classes, Named Credential metadata, deployment via sf CLI, and step-by-step Setup registration guidance for any REST API.

**Out of scope:** Configuring standard adapters (OData, Snowflake, GraphQL — those have their own flows). Generating the External Data Source metadata file (not deployable via sf CLI — must be registered manually in Setup). Writing Apex that calls external APIs outside the Salesforce Connect framework (use the platform-apex-generate or integration-connectivity-generate skills).

Before starting

Confirm two things. If either is missing, ask before proceeding.

**1. Is this actually a Salesforce Connect use case?**

| The user wants to… | Right tool | |---|---| | Query external data live without copying it — read-only or read-write, appears as Salesforce records | **This skill** | | Copy or sync data into Salesforce on a schedule | the platform-data-manage skill | | Connect to OData, GraphQL, DynamoDB, Athena, or Cross-Org | Standard adapter setup — no Apex needed, different flow | | Connect to Snowflake via Salesforce's native Snowflake adapter (direct Snowflake protocol) | Built-in Snowflake adapter — no Apex needed | | Access Snowflake (or any database) data via a REST or HTTP API | **This skill** — Snowflake REST endpoint → custom Apex adapter | | Call an external API from Apex or Flow logic | the platform-apex-generate skill or [integration-connectivity-generate](../integration-connectivity-generate/SKILL.md) | | Expose Salesforce data to an external system | [integration-connectivity-generate](../integration-connectivity-generate/SKILL.md) | | Receive real-time pushed data or subscribe to external events | Not Salesforce Connect — Connect is pull-only. Use Platform Events or Change Data Capture instead | | Sync or copy data for analytics or bulk processing | Data Cloud or ETL — Connect is zero-copy virtualization only |

If the user has a standard adapter available, tell them — writing a custom adapter when a standard one fits is unnecessary work.

**2. Do they have a Salesforce Connect license?**

A custom adapter requires a Salesforce Connect license (one license per External Data Source). Without it, the External Data Source menu won't show the Apex option. If the user doesn't have one, tell them before going further.

---

Default org context (when running locally)

If the user does not specify an org alias, use `demo-org`. If the user does not specify an SFDX project path, use `~/salesforce-connect-apex-skill/sfconnect-demo/`. These are the defaults for local testing — always override if the user specifies their own.

---

Collect inputs before generating

Never generate code without these. If any are missing, ask:

| Input | Why it matters | |---|---| | API name and what it does | Names the classes and sets context for field mapping | | Base URL | Becomes the Named Credential endpoint | | Auth type | Determines Named Credential setup and `getAuthenticationMode()` | | Key GET endpoint(s) + sample response | Defines the External Object schema — field names, types, nesting | | Write support needed? | Determines whether to implement `upsertRows()` and `deleteRows()` | | Org type (DE, scratch, sandbox) | Sets `apiVersion` in `.cls-meta.xml` |

If the user provides an OpenAPI spec, extract:

• All GET endpoints returning arrays → each becomes a `DataSource.Table`
• Response object properties → `DataSource.Column` entries
• `id` / `uuid` / primary key → map to `ExternalId`
• Property types → use the field type mapping table below

---

What to build

Every custom Salesforce Connect adapter is exactly two Apex classes.

DataSource.Connection

Handles communication with the external API. Exact signatures:

override global DataSource.TableResult query(DataSource.QueryContext context)
override global List<DataSource.TableResult> search(DataSource.SearchContext context)

// Write support — only if API supports it:
global override List<DataSource.UpsertResult> upsertRows(DataSource.UpsertContext context)
global override List<DataSource.DeleteResult> deleteRows(DataSource.DeleteContext context)

Key distinction: `query()` always operates on **one** table (`QueryContext` has a single `TableSelection`). `search()` can operate on **multiple** tables simultaneously (`SearchContext` has multiple `TableSelection` instances) — handle each in a loop and return a result per table.

DataSource.Provider

Declares the adapter's capabilities and schema to Salesforce. Required methods:

• `getAuthenticationMode()` — return `ANONYMOUS` for public A