/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. 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 — including activating/deactivating a Flow (PATCH `FlowDefinition.Metadata.activeVersionNumber` to the version, or `null`), re-pointing an OBM endpoint, updating a RemoteSiteSetting URL, or re-scheduling a ScheduledApex job after refresh. Also trigger for phrasings like \"apply post-copy config\", \"run post-copy automation\", \"activate Flow <name> post-refresh\", \"deactivate Flow <name>\", \"re-point outbound messages after refresh\", or \"configure sandbox after refresh\". Per entry, derive the Tooling API sobject, verify via describe, resolve the Id via SOQL, then PATCH the compound `Metadata` field (`ScheduledApex` uses anonymous Apex). DO NOT TRIGGER for generating config JSON from an SOP (use `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.3"
  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. Four canonical `ConfigurationName` values are pinned: `OutboundMessages` + `RemoteSiteSettings` → compound-`Metadata` PATCH (Steps A–E); `ScheduledApex` → anonymous-Apex (Step F) since `CronTrigger` is read-only; `Flows` → flow-activation (Step G), same compound-`Metadata` transport as A–E with fixed mutation key `activeVersionNumber` + state-aware pre-flight (`ALREADY_ACTIVE` / `ALREADY_INACTIVE`). Non-canonical names are derived + describe-verified. Every A–E entry must pass Step B (describe 200 + `Metadata` compound field) before any PATCH is planned; Step B skipped for `ScheduledApex`. Unverified entries are surfaced in the summary and skipped — 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` — the compound `Metadata` PATCH pattern this skill requires is not available through MCP wrappers. Invoke `sf` **without** `--target-org` when the user didn't name an alias (the harness sets the CLI default); never pass `--target-org default` (`NamedOrgNotFoundError`). SOQL-over-REST is same-OAuth — no direct DB / 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>'`. | | `ScheduledApex` | `CronTrigger` (read-only — Anonymous Apex route, see Step F) | See Step F — pre-flight `SELECT Id FROM CronTrigger WHERE CronJobDetail.Name = '<escaped>'` gate. | | `Flows` | `FlowDefinition` (compound-`Metadata` PATCH with fixed `activeVersionNumber` mutation — see Step G) | See Step G — pre-flight `SELECT Id, DeveloperName, ActiveVersion.VersionNumber FROM FlowDefinition WHERE DeveloperName = '<Fields.FlowApiName>'`. |

For canonical entries use the pinned sobject + SOQL as-is; skip "derive". Do not invent `OutboundMessage`, `RemoteSiteSetting`, or `MasterLabel` variants. 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); Step B rules out wrong guesses.