/automation-sandbox-post-copy-configure

name: automation-sandbox-post-copy-configure
description: "Apply a Salesforce sandbox post-copy automation JSON config against a target org. For each entry, the skill derives the correct Tooling API sobject from the entry's `ConfigurationName`, verifies the derivation via a describe probe, resolves the record Id via SOQL-over-REST, then PATCHes the record via the compound `Metadata` field using `sf api request rest`. Use when the user asks to apply, run, execute, dry-run, or preview a post-copy or post-refresh config file (e.g. `post-copy-config.json`) against a sandbox. Trigger phrases: \"apply post-copy config\", \"run post-copy automation\", \"execute sandbox post-refresh JSON\", \"apply sandbox refresh config\", \"configure sandbox after refresh\". DO NOT TRIGGER for generating the config JSON from an SOP (delegate to `automation-sandbox-post-copy-config-generate`), or for deploying metadata XML."
allowed-tools: Bash Read Write
metadata:
  relatedSkills:
    - "automation-sandbox-post-copy-config-generate"
    - "dx-org-permission-set-assign"
    - "platform-metadata-deploy"
  version: "1.0"
  domains: ["Automation"]
  cliTools:
    - tool: ["curl"]
      semver: ">=7.0.0"
    - tool: ["jq"]
      semver: ">=1.6"
    - tool: ["node"]
      semver: ">=18.0.0"
    - tool: ["sf"]
      semver: ">=2.0.0"

Automation: Sandbox Post-Copy Configure

Apply a Salesforce sandbox post-copy automation JSON config to a target org. The skill pins the Tooling API sobject **and** the record-lookup SOQL filter for the two canonical `ConfigurationName` values it has been calibrated against (`OutboundMessages`, `RemoteSiteSettings`); for any other `ConfigurationName` it derives a candidate from the entry value and verifies it against the live org's describe endpoint. Every entry — pinned or derived — must still pass Step B (describe returns 200 with a `Metadata` compound field) before any PATCH is planned. Entries whose API cannot be identified or verified are surfaced in the summary and skipped — they are never guessed at.

Tool Restrictions

**Use ONLY the Bash tool** to execute `sf` CLI commands (`sf data query --use-tooling-api`, `sf api request rest`, `sf org display`). Do NOT use MCP tools like `execute_soql` — ignore them completely; the compound `Metadata` PATCH pattern this skill requires is not available through MCP tool wrappers. If the target org alias is not explicitly named by the user, invoke `sf` commands **without** `--target-org` — the harness has already set the CLI's default target-org. Never pass `--target-org default` — `default` is not an alias and will fail with `NamedOrgNotFoundError`.

SOQL-over-REST (`sf data query --use-tooling-api ...`) is treated as an API call — same OAuth session, same authorization boundary as the subsequent PATCH. No direct database / non-Salesforce SQL access.

STOP — do this before making any API call

Never call the org from memory. Before the first request:

1. Read the config JSON end-to-end from the exact path the user gave (default `./post-copy-config.json`). Every entry must have all five keys (`ConfigurationName`, `Label`, `Fields`, `IsActive`, `ExecutionOrder`). If any entry is malformed, abort and surface the file path + entry index — do **not** partially apply. **Do not invent entries.** If the file is missing, stop and ask; never fabricate a plan against synthetic labels. 2. For each distinct `ConfigurationName` in the config, run the derivation + describe-verify step (below) **before** planning any PATCH. An entry whose API cannot be verified must never appear as a planned PATCH — it is rejected up front. 3. Confirm the target org alias with the user unless they supplied one explicitly. This skill mutates a live org — writing to the wrong org (e.g., a production alias set as default) is the most expensive failure mode.

If you announce "I will apply … now" without having read the config file and run the describe-verify for every distinct `ConfigurationName`, stop and do those first.

---

Per-entry procedure (the core of this skill)

The skill carries a pinned mapping for the canonical types below, and a derive-then-verify path for anything else. Follow these steps **for every entry**, in order. `Step B` (describe-verify) is mandatory regardless of whether the mapping came from the pinned table or the derive path — its HTTP status must appear in the summary.

Step A — Resolve the Tooling API sobject and lookup filter

**Pinned canonicals (authoritative — use these exactly, do NOT substitute a different sobject name):**

| ConfigurationName | Tooling API sobject | Record-lookup SOQL | |-------------------|---------------------|--------------------| | `OutboundMessages` | `WorkflowOutboundMessage` | `SELECT Id, FullName FROM WorkflowOutboundMessage WHERE EntityDefinition.QualifiedApiName = '<Fields.Object>'` — then client-side pick the row whose `FullName == '<Fields.Object>.<Label>'`. SOQL cannot filter on `FullName` directly for this sobject. | | `RemoteSiteSettings` | `RemoteProxy` | `SELECT Id, SiteName FROM RemoteProxy WHERE SiteName = '<Label>'`. |

For canonical entries use the pinned sobject and SOQL as-is; skip "derive". Do not invent `OutboundMessage`, `RemoteSiteSetting`, or `MasterLabel` variants — plausible-looking but wrong.

Field-name resolution (overrides + case rule + existence check) is owned by `scripts/map-metadata-key.mjs`.

**Non-canonical**: derive a candidate (usually singular of the Metadata API type name, sometimes prefixed); Step B rules out wrong guesses. Use the generic SOQL patterns in Step C.

Step B — Verify the candidate exists and supports Metadata writes

For each candidate, GET the describe:

sf api request rest \
  "/services/data/v<apiVersion>/tooling/sobjects/<Candidate>/describe/"

Accept the candidate only if **both** are true:

• HTTP 200 (the sobject exists on this org's Tooling API), AND
• The describe respons