/automation-sandbox-post-copy-config-generate

name: automation-sandbox-post-copy-config-generate
description: "Generates the JSON config file that the Salesforce sandbox post-copy automation tool consumes, from a customer SOP in any format (PDF, xlsx, csv, JSON, docx, Markdown, plain text, or a screenshot of an endpoint table). Use when the user asks to create, build, generate, produce, or convert a post-copy or post-refresh automation config — turning a sandbox-refresh SOP into a JSON array of OutboundMessages (OBM), RemoteSiteSettings, ScheduledApex, and Flows entries with ConfigurationName, Label, Fields, IsActive, and ExecutionOrder. Also trigger for phrasings like \"post-copy config\", \"post-refresh automation JSON\", \"update the outbound message (OBM) endpoints after refresh\", \"convert this SOP to config\", \"remote site settings JSON\", \"refresh planner to JSON\", or \"sandbox refresh config\". DO NOT TRIGGER when: user wants to deploy the generated config to an org (use platform-metadata-deploy), or apply/execute/run/dry-run the post-copy automation JSON against a sandbox (use automation-sandbox-post-copy-configure)."
metadata:
  relatedSkills:
    - "automation-sandbox-post-copy-configure"
    - "platform-metadata-deploy"
  version: "1.2"
  domains: ["Automation"]

Automation: Sandbox Post-Copy Config Generate

Convert a customer's sandbox-refresh / post-copy SOP into a structured JSON array that the post-copy automation tool consumes. Each entry is a declarative instruction: which Salesforce configuration to update, which fields are involved, whether it is active, and what order it runs in.

STOP — do this before writing any JSON

Do **not** compose the output from memory. Before you write the file, you MUST open and read `assets/config_template.json` and copy an entry from it for each action. Every output entry is exactly one of these four shapes — five top-level keys, no others, no wrapper object:

[
  {
    "ConfigurationName": "OutboundMessages",
    "Label": "IR_Account_OBM_PROD",
    "Fields": { "EndpointUrl": "https://uat.example.com/services/account", "Object": "Account" },
    "IsActive": true,
    "ExecutionOrder": 1
  },
  {
    "ConfigurationName": "RemoteSiteSettings",
    "Label": "R12_Remote_Site",
    "Fields": { "RemoteSiteUrl": "https://uat.example.com" },
    "IsActive": true,
    "ExecutionOrder": 2
  },
  {
    "ConfigurationName": "ScheduledApex",
    "Label": "Nightly Data Sync",
    "Fields": { "ApexClassName": "NightlyDataSyncScheduler", "CronExpression": "0 0 2 * * ?", "JobName": "Nightly Data Sync" },
    "IsActive": true,
    "ExecutionOrder": 3
  },
  {
    "ConfigurationName": "Flows",
    "Label": "Deactivate Nightly Sync Flow",
    "Fields": { "FlowApiName": "Nightly_Sync_Flow", "Action": "Deactivate" },
    "IsActive": true,
    "ExecutionOrder": 4
  }
]

• `ConfigurationName`: exactly `OutboundMessages`, `RemoteSiteSettings`, `ScheduledApex`, or `Flows` — these are the ONLY four valid values and they are **plural / PascalCase** (never singular `OutboundMessage`, never `Type` / `Name` / `Operation`).
• Field keys inside `Fields` are **PascalCase** verbatim: `EndpointUrl`, `Object`, `RemoteSiteUrl`, `ApexClassName`, `CronExpression`, `JobName`, `FlowApiName`, `Action`, `VersionNumber` — never lowercase (`endpointUrl`), never duplicated at the top level (no `isActive`/`Label` inside `Fields` — those already live at the top level of the entry).
• OBM `Fields`: `EndpointUrl` + `Object` (both required). RemoteSite `Fields`: `RemoteSiteUrl` only — never `Url`/`RemoteSiteURL`. ScheduledApex `Fields`: `ApexClassName` + `CronExpression` + `JobName` (all three required). Flows `Fields`: `FlowApiName` + `Action` (both required); `Action` is exactly `"Activate"` or `"Deactivate"`; optional `VersionNumber` (positive integer) is meaningful only for `Activate`.
• `ExecutionOrder` is a **phase number**, not a per-row counter. The `1, 2, 3, 4` in the template above only differ because each example is a different entry type. **Multiple entries of the same type with no dependency on each other share the same number** — e.g., three independent OBMs all get `ExecutionOrder: 1`.
• Top level is a JSON array. No `steps`/`actions`/`records` wrapper. No `<…>` or `REPLACE_WITH_…` placeholder ever survives into the output.

If you announce "I will now write …" without having read the template and catalog, stop and read them first — a from-memory guess produces the wrong keys and fails at runtime.

Scope

• **In scope**: Reading a customer SOP in any of the supported formats

(PDF, xlsx, csv, JSON, docx, Markdown, plain text, pasted excerpt, or images containing data tables — e.g., a screenshot of an Outbound Messages list with endpoint URLs), identifying post-copy / post-refresh actions, mapping each action to a supported `ConfigurationName`, emitting the canonical JSON array.

• **Out of scope**: Generating Salesforce metadata XML (delegate to

`generating-*` skills), deploying anything to an org, running the post-copy tool, inferring or fabricating values not present in the SOP — if the SOP does not give a concrete URL/value for an action, skip the action.

**Every emitted entry must have every Field populated with a real value from the customer source.** No empty strings, no `null`, no `<from-backup>` / `TBD` / `TODO` placeholders. Customers should never see an unpopulated field in the output — if a value cannot be located, skip the entry and surface it. See the corresponding rule below.

---

Required Inputs

Gather or infer before generating:

• **SOP source(s)**: One or more paths (or pasted content) in any of:

PDF, xlsx, csv, JSON, docx, Markdown, plain text, or images (.png/.jpg/.jpeg/.tiff/.bmp). Multiple files are common — the action list and the endpoint table sometimes live in different files. Read every file the user supplies.

• **Target output path**: Where the JSON config should be written. Default

to `post-copy-config.json` in the current dir