
This handles Salesforce data operations when you need to create test records, run bulk imports/exports, or seed orgs for validation work. It wraps the sf data CLI and knows when to use bulk versus single-record commands, when to generate reusable scripts versus touching a live org, and how to build realistic test datasets with parent-child relationships. The 130-point scoring system pushes you toward describe-first validation, cleanup discipline, and bulk-safe patterns like 251+ records for automation testing. Honestly most useful when you're setting up test data factories or need reversible experiment patterns with exact rollback commands instead of guessing your way through CSV imports.
$ npx -y skills add jaganpro/sf-skills --skill sf-data --agent claude-codeInstalls into .claude/skills of the current project.
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.
Use sf-data when the work involves:
sf data CLI commandsDelegate elsewhere when the user is:
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.
Ask for or infer:
sf-data acts on remote org data unless the user explicitly wants local script generation.If metadata is missing, stop and hand off to:
Confirm object / field availability, org auth, and required parent records.
Before creating or updating records, use object describe data to validate:
Example pattern:
sf sobject describe --sobject ObjectName --target-org <alias> --json
Helpful filters:
# Required + createable fields
jq '.result.fields[] | select(.nillable==false and .createable==true) | {name, type}'
# Valid picklist values for one field
jq '.result.fields[] | select(.name=="StageName") | .picklistValues[].value'
# Fields that cannot be set on create
jq '.result.fields[] | select(.createable==false) | .name'
| 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 |
Use the built-in templates under assets/ when they fit:
assets/factories/assets/bulk/assets/cleanup/assets/soql/assets/csv/assets/json/Check counts, relationships, and record IDs after creation or update.
If creation fails:
Do not repeat the same failing command indefinitely.
Provide exact cleanup commands or rollback assets whenever data was created.
Prefer one of:
| Error | Likely cause | Default fix direction |
|---|---|---|
INVALID_FIELD | wrong field API name or FLS issue | verify schema and access |
REQUIRED_FIELD_MISSING | mandatory field omitted | include required values from describe data |
INVALID_CROSS_REFERENCE_KEY | bad parent ID | create / verify parent first |
FIELD_CUSTOM_VALIDATION_EXCEPTION | validation rule blocked the record | use valid test data or adjust setup |
| invalid picklist value | guessed value instead of describe-backed value | inspect picklist values first |
| non-writeable field error | field is not createable / updateable | remove it from the payload |
| bulk limits / timeouts | wrong tool for the volume | switch to bulk / staged import |
When finishing, report in this order:
Suggested shape:
Data operation: <create / update / delete / export / seed>
Objects: <object + counts>
Target: <org alias or local path>
Artifacts: <record ids / csv / apex / json files>
Verification: <passed / partial / failed>
Cleanup: <exact delete or rollback guidance>
| Need | Delegate to | Reason |
|---|---|---|
| discover object / field structure | sf-metadata | accurate schema grounding |
| run bulk-sensitive Apex validation | sf-testing | test execution and coverage |
| deploy missing schema first | sf-deploy | metadata readiness |
| implement production logic consuming the data | sf-apex or sf-flow | behavior implementation |
| Score | Meaning |
|---|---|
| 117+ | strong production-safe data workflow |
| 104–116 | good operation with minor improvements possible |
| 91–103 | acceptable but review advised |
| 78–90 | partial / risky patterns present |
| < 78 | blocked until corrected |
Sponsors