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 directory unless specified.
• Scope filter (optional): If the SOP covers many environments (e.g., fcQA, fcUAT, multiple sandboxes), confirm which subset the user wants in the output.

If the user provides a clear SOP and target, generate immediately without asking unnecessary questions.

Workflow

All steps are sequential. Steps 1–5 (reading the SOP, the catalog, the template, and the schema) are prerequisites to writing — you may not skip to the write step. If you catch yourself about to emit JSON without having read assets/config_template.json and references/configuration_catalog.md, go back and read them first.

1. Locate and read every supplied SOP source — read references/source_format_handling.md for the exact extraction recipe per format (PDF, xlsx, csv, JSON, docx, image). At a glance:

   • PDF: extract text with pypdf (text layer) and OCR image-based pages with pytesseract if the text layer is empty.
   • xlsx: read every sheet with openpyxl (data_only=True), scan all columns including ones outside the visible default range, check cell comments and embedded media.
   • csv / JSON / Markdown / text: read directly.
   • docx: extract paragraphs and tables with python-docx.
   • Images (.png/.jpg/...): use the Read tool to view, then decide if the image carries data (a table of endpoint URLs, a setup screenshot showing values to capture) or is purely illustrative (architecture diagram, flow chart). Extract values only from data-bearing images. See the image-handling rules in references/source_format_handling.md.
   • For very large SOPs (>50 pages / >20 sheets), focus on sections or sheets titled "Post Refresh", "Post-Copy", "Post-Refresh Steps", "Update …", or equivalent.

2. Identify post-copy actions — read references/sop_parsing_patterns.md for the heuristics that turn prose instructions ("Update Outbound Message endpoint X to URL Y") into structured action records.

3. Map each action to a ConfigurationName — load references/configuration_catalog.md. The catalog currently supports OutboundMessages, RemoteSiteSettings, ScheduledApex, and Flows. Any action that targets a different configuration type is out of scope: skip it and list it in the response so the user can extend the catalog later.

4. Read the JSON template — load assets/config_template.json. It shows the exact required shape of one OutboundMessages entry, one RemoteSiteSettings entry, one ScheduledApex entry, and one Flows entry, with <…> placeholder slots. Copy an entry, replace every <…> slot with the concrete SOP value, and keep the exact top-level keys (ConfigurationName, Label, Fields, IsActive, ExecutionOrder) — never rename them to Type, Name, Operation, etc. Never emit an entry that still contains a <…> placeholder; if you cannot fill a slot, skip the entry (see Rules).

5. Validate against the schema — load assets/json_schema.json. Every entry must conform: ConfigurationName is one of the catalog values, Fields is an object, IsActive is boolean, ExecutionOrder is a positive integer.

6. Group entries by phase, then assign ExecutionOrder — ExecutionOrder is a phase number, not a per-row counter. Entries that can run in parallel (no dependency between them) share the same value. Different ConfigurationName types typically get different phases; all entries within one phase share its number. See the ordering heuristic in references/sop_parsing_patterns.md.

7. Compare against the example — verify the output shape against examples/sample_sop_to_config.json before writing.

8. Write the JSON file — emit pretty-printed JSON (2-space indent).

Rules / Constraints

Canonical entry shape

See the entry shapes shown in the STOP section above, or copy directly from assets/config_template.json. Do not rename the five top-level keys (ConfigurationName, Label, Fields, IsActive, ExecutionOrder) to Type, Name, Operation, apiName, etc., and do not wrap the array in an object with a steps / actions / records key.

Gotchas

Output Expectations

Deliverables:

• A single JSON file (default post-copy-config.json) containing a top-level array of post-copy action entries.
• A short summary in your response listing: total entries, count per ConfigurationName, actions skipped because they did not map to the catalog, and actions skipped because the SOP did not include a concrete value.

The output file structure conforms to assets/json_schema.json.

Cross-Skill Integration

Reference File Index