/platform-data-manage

name: platform-data-manage
description: "Salesforce data operations with 130-point scoring. Use to create, update, delete, bulk import/export, generate test data, and clean up org records via sf CLI and anonymous Apex. TRIGGER on creating test data, bulk import/export, sf data CLI commands, data-factory patterns for Apex tests, or seeding/cleaning org records. DO NOT TRIGGER for SOQL query writing only (use platform-soql-query), Apex test execution (use platform-apex-test-run), or metadata deployment (use platform-metadata-deploy)."
metadata:
  version: "1.1"
  domains: ["Platform"]
  relatedSkills:
    - "automation-flow-generate"
    - "platform-apex-generate"
    - "platform-apex-test-run"
    - "platform-custom-field-generate"
    - "platform-custom-object-generate"
    - "platform-metadata-deploy"
    - "platform-soql-query"
  cliTools:
    - tool: ["sf"]
      semver: ">=2.0.0"
    - tool: ["jq"]
      semver: ">=1.6.0"
    - tool: ["python3"]
      semver: ">=3.8.0"

Salesforce Data Operations Expert (platform-data-manage)

Use this skill when the user needs **Salesforce data work**: record CRUD, bulk import/export, test data generation, cleanup scripts, or data factory patterns for validating Apex, Flow, or integration behavior.

When This Skill Owns the Task

Use `platform-data-manage` when the work involves:

• `sf data` CLI commands
• record creation, update, delete, upsert, export, or tree import/export
• realistic test data generation
• bulk data operations and cleanup
• Apex anonymous scripts for data seeding / rollback

Delegate elsewhere when the user is:

• writing SOQL only → [platform-soql-query](../platform-soql-query/SKILL.md)
• running or repairing Apex tests → [platform-apex-test-run](../platform-apex-test-run/SKILL.md)
• deploying metadata first → [platform-metadata-deploy](../platform-metadata-deploy/SKILL.md)
• creating or modifying custom objects / fields → [platform-custom-object-generate](../platform-custom-object-generate/SKILL.md) or [platform-custom-field-generate](../platform-custom-field-generate/SKILL.md)

---

Important Mode Decision

Confirm which mode the user wants:

| Mode | Use when | |---|---| | Script generation | they want reusable `.apex`, CSV, or JSON assets without touching an org yet | | Remote execution | they want records created / changed in a real org now |

Do not assume remote execution if the user may only want scripts.

---

Required Context to Gather First

Ask for or infer:

• target object(s)
• org alias, if remote execution is required
• operation type: query, create, update, delete, upsert, import, export, cleanup
• expected volume
• whether this is test data, migration data, or one-off troubleshooting data
• any parent-child relationships that must exist first

---

Core Operating Rules

• `platform-data-manage` acts on **remote org data** unless the user explicitly wants local script generation.
• Objects and fields must already exist before data creation.
• For automation testing, prefer **251+ records** when bulk behavior matters.
• Plan cleanup before creating large or noisy datasets — untracked records accumulate across runs and pollute org state.
• Use synthetic, non-identifying data in test records — real PII creates compliance risk and cannot be safely removed after bulk import.
• Prefer **CLI-first** for straightforward CRUD; use anonymous Apex when the operation truly needs server-side orchestration.

If metadata is missing, stop and hand off to:

• [platform-custom-object-generate](../platform-custom-object-generate/SKILL.md) or [platform-custom-field-generate](../platform-custom-field-generate/SKILL.md) to create the missing schema, then [platform-metadata-deploy](../platform-metadata-deploy/SKILL.md) to deploy it before retrying the data operation

---

Recommended Workflow

1. Verify prerequisites

Confirm object / field availability, org auth, and required parent records.

2. Run describe-first pre-flight validation when schema is uncertain

Before creating or updating records, use object describe data to validate:

• required fields
• createable vs non-createable fields
• picklist values
• relationship fields and parent requirements

See [references/sf-cli-data-commands.md](references/sf-cli-data-commands.md) for the `sf sobject describe` command and jq filter patterns for inspecting fields, picklist values, and createable constraints.

3. Choose the smallest correct mechanism

| Need | Default approach | |---|---| | small one-off CRUD | `sf data` single-record commands | | large import/export | Bulk API 2.0 via `sf data ... bulk` | | parent-child seed set | tree import/export | | reusable test dataset | factory / anonymous Apex script | | reversible experiment | cleanup script or savepoint-based approach |

4. Execute or generate assets

Use the built-in templates under `assets/` when they fit:

• `assets/factories/`
• `assets/bulk/`
• `assets/cleanup/`
• `assets/soql/`
• `assets/csv/`
• `assets/json/`

5. Verify results

Check counts, relationships, and record IDs after creation or update.

6. Apply a bounded retry strategy

If creation fails: 1. try the primary CLI shape once 2. retry once with corrected parameters 3. re-run describe / validate assumptions 4. pivot to a different mechanism or provide a manual workaround

Do **not** repeat the same failing command indefinitely.

7. Leave cleanup guidance

Provide exact cleanup commands or rollback assets whenever data was created.

---

High-Signal Rules

Bulk safety

• use bulk operations for large volumes
• test automation-sensitive behavior with 251+ records where appropriate
• avoid one-record-at-a-time patterns for bulk scenarios

Data integrity

• include required fields
• validate picklist values before creation
• verify parent IDs and relationship integrity
• account for validation rules and duplicate constraints
• exclude non-createable fields from input payloads

Cleanup discipline

Prefer one of: