sf-datacloud-connect: Data Cloud Connect Phase

Use this skill when the user needs source connection work: connector discovery, connection metadata, connection testing, browsing source objects, or understanding what connector type to use.

When This Skill Owns the Task

Use sf-datacloud-connect when the work involves:

sf data360 connection *
connector catalog inspection
connection creation, update, test, or delete
browsing source objects, fields, databases, or schemas
identifying connector types already in use

Delegate elsewhere when the user is:

creating data streams or DLOs → sf-datacloud-prepare
creating DMOs, mappings, IR rulesets, or data graphs → sf-datacloud-harmonize
writing Data Cloud SQL or search-index workflows → sf-datacloud-retrieve

Required Context to Gather First

Ask for or infer:

target org alias
connector type or source system
whether the user wants inspection only or live mutation
connection name if one already exists
whether credentials are already configured outside the CLI

Core Operating Rules

Verify the plugin runtime first; see ../sf-datacloud/references/plugin-setup.md.
Run the shared readiness classifier before mutating connections: node ~/.claude/skills/sf-datacloud/scripts/diagnose-org.mjs -o <org> --phase connect --json.
Prefer read-only discovery before connection creation.
Suppress linked-plugin warning noise with 2>/dev/null for standard usage.
Remember that connection list requires --connector-type.
Discover existing connector types from streams first when the org is unfamiliar.
API-based external connector creation is supported, but payloads are connector-specific.
Do not use query-plane errors from other phases to declare connect work unavailable.

Recommended Workflow

1. Classify readiness for connect work

node ~/.claude/skills/sf-datacloud/scripts/diagnose-org.mjs -o <org> --phase connect --json

2. Discover connector types

sf data360 connection connector-list -o <org> 2>/dev/null
sf data360 data-stream list -o <org> 2>/dev/null

3. Inspect connections by type

sf data360 connection list -o <org> --connector-type SalesforceDotCom 2>/dev/null
sf data360 connection list -o <org> --connector-type REDSHIFT 2>/dev/null

4. Inspect a specific connection

sf data360 connection get -o <org> --name <connection> 2>/dev/null
sf data360 connection objects -o <org> --name <connection> 2>/dev/null
sf data360 connection fields -o <org> --name <connection> 2>/dev/null

5. Test or create only after discovery

sf data360 connection test -o <org> --name <connection> 2>/dev/null
sf data360 connection create -o <org> -f connection.json 2>/dev/null

6. Start from curated example payloads for external connectors

Use the phase-owned examples before inventing a payload from scratch:

examples/connections/heroku-postgres.json
examples/connections/redshift.json

To discover payload fields for a connector type not covered by those examples, create one in the UI and inspect it:

sf api request rest "/services/data/v66.0/ssot/connections/<id>" -o <org>

High-Signal Gotchas

connection list has no true global "list all" mode; query by connector type.
The connection catalog name and connection connector type are not always the same label.
Some external connector credential setup still depends on UI-side configuration.
Use connection metadata inspection before guessing available source objects or databases.
An empty connection list usually means "enabled but not configured yet", not "feature disabled".
Heroku Postgres and Redshift payloads use different credential / parameter names. Reuse the curated examples instead of guessing.

Output Format

Connect task: <inspect / create / test / update>
Connector type: <SalesforceDotCom / REDSHIFT / S3 / ...>
Target org: <alias>
Commands: <key commands run>
Verification: <passed / partial / blocked>
Next step: <prepare phase or connector follow-up>

sf-datacloud-connect