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 v

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: Accept the candidate only if both are true: HTTP 200 (the sobject exists on this org's Tooling API), AND The describe response's fields array contains a field named Metadata (compound field — this is what PATCH writes through). If no candidate passes both gates, mark the entry API NOT IDENTIFIED and skip. Do not guess a REST path — the wrong path 404s in the best case and updates the wrong record in the worst case. Step C — Resolve the record Id (SOQL over REST) For pinned canonicals : run the SOQL from the Step A table verbatim (substituting <Label / <Fields.Object ). Do not substitute a different filter column such as MasterLabel — the pinned SOQL is the tested and correct filter for that sobject. For non canonical (derived) sobjects : query the verified sobject for the record identified by the entry's Label (and Fields.Object when present): Pick <UniqueFilter based on the queryable fields shown in the describe response from Step B. If the row contains a FullName field, SOQL usually rejects a direct FullName = ... filter — filter by whichever direct column the describe surfaces (e.g. EntityDefinition.QualifiedApiName , DeveloperName , SiteName ) and apply the FullName match client side ( jq r '.result.records[] select(.FullName == "<Object .<Label ") .Id' ). Outcomes: Zero rows → NOT FOUND (never fall back to insert). Multiple rows after client side filtering → AMBIGUOUS (surface all Ids in the summary and skip; a wrong Id is worse than no Id). Exactly one row → proceed to Step D. Step D — GET current Metadata, mutate, PATCH back Metadata is replace in full — omitted keys are blanked on PATCH. Preserve every existing key from the Step D 1 GET; overlay only the mutated keys. The summary's "planned PATCH body" (apply and dry run) is this full merged object — verbose or org specific values may render as "<preserved from GET " in dry run, but every key must be present. Every Step D filename must include the record <Id from Step C (e.g. /tmp/entry <Id meta.json ) — phase parallel entries share the working directory and would clobber a shared name. 1. GET current Metadata → /tmp/entry <Id meta.json . 2. Resolve the mutation key — for each Fields.<Xxx , run node scripts/map metadata key.mjs "<ConfigurationName " "<ConfigFieldName " /tmp/entry <Id meta.json . On {"status":"OK","key":...} use the returned key. On {"status":"FIELD MAP UNKNOWN",...} mark the entry and skip. 3. PATCH — heredoc build /tmp/entry <Id mutation.json , merge with jq slurpfile m /tmp/entry <Id mutation.json '. + $m[0] {Metadata: .}' /tmp/entry <Id meta.json /tmp/entry <Id patch.json (preserves JSON types), PATCH with b @/tmp/entry <Id patch.json , capture the response body to /tmp/entry <Id response.json . Full bash in references/api endpoints.md §Step D. Never use arg (stringifies booleans/numbers, breaks on special chars). Wrap the PATCH in for attempt in 1 2; do <cmd && break; done — retry once on shell/jq quoting failure (non zero exit before the HTTP call goes out). 4. Classify — node scripts/classify patch result.mjs "<httpCode " /tmp/entry <Id response.json . Exit 0 → SUCCESS ; exit 2 → FAILED (parsed error on stdout). 204 with a non empty body is FAILED . Step E — Verify the change landed Re read the record to confirm the PATCH stuck: If the mutated field is a direct queryable SOQL column on the sobject (rare — most Metadata writable fields are not), a SELECT by Id is enough. Otherwise GET the record and inspect the corresponding key inside .Metadata . If the read back value doesn't match the requested value, record FAILED VERIFY — the PATCH returned 204 but the effect is not visible (usually a naming or permission issue). IsActive semantics IsActive: true → apply the PATCH as described in Steps A–E. IsActive: false → do not PATCH . Record SKIPPED INACTIVE for the entry and add a bullet under Follow ups in the summary file listing the entry's ConfigurationName + Label so the customer notices that a config declared inactive record was left untouched on the target org. Rationale: IsActive: false means "not active in this sandbox", not "deactivate the existing record". Silently deactivating a live integration is a much bigger blast radius than leaving it alone. Canonical output shape (always emit this) Single Markdown summary written to ./post copy <mode summary.md (mode is dry run or apply ) AND printed to the user. No JSON side files ( plan/phases.json , requests/ .request.json , etc.) — inline every planned/actual request in the Markdown. Phase enumeration is script owned. Run node scripts/plan phases.mjs <config.json and consume its phases[] output verbatim. Each entry carries ordinal (1 indexed phase number) and executionOrder (raw value, for the (ExecutionOrder = <raw ) heading annotation). Sparse values collapse ( 1, 2, 5 → ordinals 1, 2, 3 ). IsActive:false entries are pre marked SKIP INACTIVE . See references/execution phasing.md for the worked example. For dry run entries the HTTP column is — (em dash). End the summary with: No PATCH requests were issued. To apply, re run without the dry run flag. Target org resolution is script owned. Run node scripts/resolve target org.mjs ; substitute the returned .alias into the header. Never emit <env:SF TARGET ORG or $SF TARGET ORG verbatim. Column semantics: Object = the entry's Fields.Object if present, — otherwise. Sobject = the Step A resolved sobject. Describe = the Step B describe HTTP status ( 200 for verified, 404 for API NOT IDENTIFIED ) — mandatory so skipped Step Bs are visible at a glance. Outcome vocabulary: SUCCESS , NOT FOUND , AMBIGUOUS , API NOT IDENTIFIED , FIELD MAP UNKNOWN , FAILED , FAILED VERIFY , SKIPPED INACTIVE , SKIPPED , DRY RUN , DELETE NOT SUPPORTED , NOT ATTEMPTED . Scripts are internal. The plan phases.mjs , map metadata key.mjs , classify patch result.mjs , resolve target org.mjs invocations are implementation detail — do not inline their raw stdout, JSON output, or "I ran node …" narration into the summary Markdown or the printed response. Consume the JSON, use the returned values, and render the summary in the exact shape above. Scope In scope : Reading a post copy config JSON (the shape produced by automation sandbox post copy config generate ), grouping entries into ExecutionOrder phases, deriving+verifying the Tooling API sobject for each entry, resolving Ids via SOQL over REST, PATCHing via compound Metadata , and reporting per entry outcomes. Out of scope : Generating the config JSON from an SOP (delegate to automation sandbox post copy config generate ); deploying metadata XML; running the Async Task Framework (ATF) orchestrator itself (that is the platform side Java implementation); inventing API paths for ConfigurationName values whose describe probe fails (surface as API NOT IDENTIFIED and stop). Every API call is against a live org. Treat this skill as a mutation tool: prefer dry run first, confirm the target org alias, and never silently retry a failed entry against a different endpoint. Required Inputs Gather or infer before applying: Config file path : Path to the JSON produced by automation sandbox post copy config generate (default: ./post copy config.json in the current directory). If the file does not exist, stop and ask. Target org alias / username : The sf CLI alias or u

automation-sandbox-post-copy-configure