salesforce-bulk-data-ops-skill

salesforce-bulk-data-ops-skill

Pure-generation T0 skill that produces production-safe scripts for bulk Salesforce data operations. Outputs both:

1. Data Loader CSV transformation templates — ready-to-use column

mappings and example CSV structures for the Salesforce Data Loader

1. Anonymous Apex scripts — safe for sf apex run --file in sandbox,

with bulkification, error queues, partial success handling, and audit logging built in

Nothing is executed by this skill. Execution requires human review, sandbox dry-run via salesforce-deployment-validator-skill, and production approval via salesforce-live-guard-agent.

When This Skill Owns the Task

Use salesforce-bulk-data-ops-skill when the work is to generate the script or template for a bulk data operation:

• "Generate an Apex script to reassign all Opportunities from user A to user B"
• "Write a Data Loader CSV template to bulk update the Account rating field"
• "Create an Anonymous Apex script to close stale Opportunities older than 90 days"
• "Generate a deduplication script using the MergeOpportunities pattern"
• "Write a batch script to deactivate inactive Contacts"
• "Build a lead conversion script for marketing-qualified leads"

Delegate elsewhere when:

| Situation | Skill to use | |---|---| | Single record lookup or spot update | salesforce-soql-explorer-skill → handoff | | Permanent hard-delete of records | T3 prohibited — route to salesforce-live-guard-agent | | Schema changes (add/remove fields) | salesforce-metadata-fetcher-skill | | Sandbox dry-run execution of generated scripts | salesforce-deployment-validator-skill | | Production approval for execution | salesforce-live-guard-agent | | Field mapping for migration CSV | salesforce-field-mapping-skill |

Required Context to Gather First

Before generating any bulk script, confirm:

1. Operation type — update, upsert, merge/deduplicate, or soft-delete.

Never hard-delete (T3 prohibited).

1. Target object — standard (Account, Opportunity, Contact, Lead)

or custom (Custom_Object__c).

1. Filter criteria — which records should be affected? Be specific

(date range, owner, status field value, etc.)

1. Volume estimate — approximately how many records? Determines batching

strategy (Apex batch classes vs. one-shot anonymous Apex).

1. Key field for targeting — what uniquely identifies the records?

(Owner Id, Status, Age, External ID)

1. Rollback plan — has the user confirmed they have a backup or can

use the Recycle Bin? Field History Tracking status?

1. Sandbox first — confirm the user will run in sandbox before

production. Explicit warning required for production-bound scripts.

1. Audit logging requirement — should the script log changes to a

custom audit object?

If any critical context is missing for the specific operation, ask before generating.

Recommended Workflow

Step 1 — Classify the operation and select the right template

| Operation | Recommended approach | |---|---| | Owner reassignment (< 10k records) | Anonymous Apex with Database.update + allOrNone=false | | Owner reassignment (> 10k records) | Apex Batch class | | Mass field update (< 10k records) | Anonymous Apex OR Data Loader Update | | Mass field update (> 10k records) | Data Loader Update with CSV OR Apex Batch | | Deduplication / merge | Anonymous Apex using Database.merge (limit 3 records per merge call) | | Bulk close stale records | Anonymous Apex with date filter and Database.update | | Contact deactivation | Anonymous Apex (no delete — soft-deactivate via HasOptedOutOfEmail and custom status field) | | Lead conversion | Anonymous Apex using Database.convertLead |

Step 2 — Generate the backup strategy

Before generating the execution script, generate the backup query:

// Backup: export records before modification
List<Opportunity> backupRecords = [
    SELECT Id, OwnerId, StageName, CloseDate, Amount
    FROM Opportunity
    WHERE <your_filter>
    LIMIT 10000
];
// Export this list to CSV before running the update script
System.debug(JSON.serialize(backupRecords));

Include a Data Loader SELECT template to export the affected records before modification.

Step 3 — Generate the Apex script with safety patterns

Apply these mandatory patterns in every Apex script:

• Chunk records into batches of 200 (Apex DML limit)
• Use Database.update(records, false) (allOrNone=false for partial success)
• Collect and log errors from Database.SaveResult[]
• Do not perform DML inside loops
• Use governor-limit-safe chunking for large volumes

Step 4 — Add audit logging

For every script that mutates records, add an audit log:

// Audit log pattern
List<Bulk_Op_Log__c> auditEntries = new List<Bulk_Op_Log__c>;
for (Database.SaveResult sr : results) {
    if (!sr.isSuccess) {
        auditEntries.add(new Bulk_Op_Log__c(
            Operation__c = 'MassOwnerReassign',
            Record_Id__c = sr.getId,
            Error_Message__c = sr.getErrors[0].getMessage,
            Timestamp__c = DateTime.now
        ));
    }
}
if (!auditEntries.isEmpty) {
    Database.insert(auditEntries, false);
}

Step 5 — Generate Data Loader template if requested

Produce a Data Loader–ready CSV header row and example data row for the operation. Include the Id column and the fields being updated.

Step 6 — Emit structured output with T2/T3 caveats

Include explicit execution pathway guidance in the output.

Quality Scoring Rubric (100-point)

Score every output before emitting. Threshold: 85+ ship, 70–84 ship with caveat, below 70 reject and revise.

| Dimension | Points | What earns full marks | |---|---|---| | Bulkification | 25 | No DML inside loops; records chunked to 200 per batch; collection-based update pattern used | | Error queue / partial success handling | 20 | Database.update with allOrNone=false; SaveResult[] iterated; failed records collected and logged; script continues after partial failure | | Idempotency | 15 | Script can be safely re-run without double-applying changes; uses a status field or processed flag; duplicate detection included | | Null handling | 15 | All field accesses null-guarded; SOQL WHERE clause handles null fields; no NullPointerException risk | | Audit logging | 15 | Every failure logged with record ID and error message; success count logged; custom audit object or System.debug used | | Rollback strategy | 10 | Backup SOQL query provided; Recycle Bin / Field History notes included; hard-delete refused with T3 note |

Scoring penalties:

• DML inside a loop: -30 (automatic reject and revision required)
• allOrNone=true on a bulk operation: -20
• No backup query provided: -15
• Hard-delete operation generated: automatic reject (T3 prohibited)
• Script will fail on null field access: -15 per unguarded access

T0 Contract / T2 Execution Note

This skill is static-review (T0) only:

• No Salesforce org connection required or permitted.
• No CLI commands are executed.
• Generated scripts are text only — not executed by this skill.

T2 Dry-Run Execution Path

1. Review generated script with your admin team.
2. Run in sandbox using sf apex run --file <script.apex> --target-org <sandbox-alias>

via salesforce-deployment-validator-skill.

1. Verify results in sandbox before proceeding.
2. For production execution: route to salesforce-live-guard-agent for

human-approval workflow.

T3 Prohibition

Hard-deletes (Database.delete followed by Database.emptyRecycleBin, or DELETELIST in Data Loader) are T3 prohibited. This skill will not generate hard-delete scripts. All delete patterns use Salesforce native soft-delete (Recycle Bin).

Refusal Triggers

Stop and decline if:

• The request is to generate a hard-delete script (emptyRecycleBin,

DELETELIST without recycle bin). Explain T3 prohibition.

• The request is t