developing-datacloud-code-extension
forcedotcom/sf-skills
How to install developing-datacloud-code-extension
npx skills add https://github.com/forcedotcom/sf-skills --skill developing-datacloud-code-extensionFull instructions (SKILL.md)
Source of truth, from forcedotcom/sf-skills.
name: developing-datacloud-code-extension description: "Develop and deploy Data Cloud Code Extensions using SF CLI plugin. Use this skill when creating custom Python transformations for Data Cloud, deploying code extensions, or testing data transformations. Supports init, run, scan, and deploy operations." metadata: version: "1.0"
developing-datacloud-code-extension Skill
Overview
This skill provides a complete workflow for developing, testing, and deploying custom Python code extensions to Salesforce Data Cloud. Code extensions allow you to write Python transformations that read from and write to Data Lake Objects (DLOs) and Data Model Objects (DMOs).
When to Use
- User wants to create a new code extension project
- User needs to test a code extension locally
- User wants to scan code for required permissions
- User needs to deploy a code extension to Data Cloud
- User is working with Data Cloud transformations
- User wants to read/write DLO or DMO data programmatically
Prerequisites Check
Before executing any code extension commands, verify prerequisites:
-
SF CLI with plugin installed
sf plugins --core | grep data-code-extensionIf not installed:
sf plugins install @salesforce/plugin-data-codeextension -
Python 3.11
python --version # Should show 3.11.x -
Data Cloud Custom Code SDK
pip list | grep salesforce-data-customcodeIf not installed:
pip install salesforce-data-customcode -
Docker running (for deploy only)
docker ps -
Authenticated org
sf org display --target-org <org_alias> --json
Skill Workflow
Phase 1: Initialize Project
Create a new code extension project with scaffolding.
Commands:
For script-based code extensions (batch transformations):
sf data-code-extension script init --package-dir <directory>
For function-based code extensions (real-time):
sf data-code-extension function init --package-dir <directory>
Required Option:
--package-dir, -p- Directory path where the package will be created
What it creates:
my-transform/ # Project root
├── payload/ # CRITICAL: This is what --package-dir must point to for deploy
│ ├── entrypoint.py # Main transformation code
│ └── config.json # Code extension configuration
├── requirements.txt # Python dependencies
└── README.md
Directory Context During Workflow
IMPORTANT: Understanding the directory structure is critical for successful deployment.
Commands and their directory requirements:
| Command | Run From | Path/File Argument |
|---|---|---|
init | Parent directory | <project-name> or . |
scan | Project root | ./payload/entrypoint.py |
run | Project root | ./payload/entrypoint.py |
deploy | Project root | --package-dir ./payload (REQUIRED) |
CRITICAL: The --package-dir argument in deploy command MUST point to the payload directory, not the project root.
Phase 2: Develop Transformation
Edit payload/entrypoint.py with transformation logic.
Script Example (Batch):
from datacustomcode import Client
client = Client()
# Read from DLO
df = client.read_dlo('Employee__dll')
# Transform data (uppercase position field)
df['position_upper'] = df['position'].str.upper()
# Write to output DLO
client.write_to_dlo('Employee_Upper__dll', df, 'overwrite')
Function Example (Real-time):
from datacustomcode import FunctionClient
def transform(event, context):
client = FunctionClient(context)
input_data = event['data']
output = {
'name': input_data['name'].upper(),
'status': 'processed'
}
return output
Common Operations:
client.read_dlo('DLO_Name__dll')- Read from DLOclient.read_dmo('DMO_Name')- Read from DMOclient.write_to_dlo('DLO_Name__dll', df, 'overwrite')- Write to DLOclient.write_to_dmo('DMO_Name', df, 'upsert')- Write to DMO
Phase 3: Scan for Permissions
Scan the entrypoint file to detect required permissions and generate config.json.
Command:
sf data-code-extension script scan --entrypoint ./payload/entrypoint.py
What it detects:
- Read permissions for DLOs/DMOs
- Write permissions for DLOs/DMOs
- Python package dependencies
- Updates
config.jsonandrequirements.txt
Phase 4: Validate DLO Schema (Pre-Test Check)
CRITICAL: Before running tests locally, validate that all DLOs used in your code exist and have the expected fields.
Step 4a: Extract DLOs from config.json
After scanning, review the generated config.json to identify all DLOs:
cat payload/config.json
Step 4b: Validate Each DLO Schema
Use the getting-datacloud-schema skill to verify DLOs exist and check field names.
For each DLO referenced in your code:
-
Verify DLO exists:
python3 scripts/get_dlo_schema.py <org_alias> <dlo_name> -
Verify field names match — compare fields used in your
entrypoint.pyagainst the DLO schema. -
Check all DLOs:
- Validate all DLOs in
readpermissions - Validate all DLOs in
writepermissions - Check field names match exactly (case-sensitive)
- Verify data types are compatible with operations
- Validate all DLOs in
Step 4c: Validation Checklist
Before proceeding to run, ensure:
- All DLOs in config.json exist in target org
- All field names used in code exist in DLO schemas
- Field data types match your transformation logic
- Primary key fields are correctly identified
- Write target DLOs are created and accessible
Phase 5: Test Locally
After validating DLO schemas, run the code extension locally against your Data Cloud org.
Command:
sf data-code-extension script run --entrypoint <entrypoint_file> --target-org <org_alias> [options]
Options:
--target-org, -o- SF CLI org alias (required)--config-file, -c- Custom config file path
If you get errors:
- Re-validate DLO schemas
- Check field names are exact matches
- Verify data types are compatible
- Review error messages for field/DLO issues
Phase 6: Deploy to Data Cloud
Deploy the code extension to Data Cloud for scheduled or on-demand execution.
CRITICAL: You MUST specify --package-dir ./payload to point to the payload directory created by init.
Command:
sf data-code-extension script deploy --target-org <org_alias> --name <name> --package-dir ./payload --package-version <version> --description <description> [options]
Required Options:
--target-org, -o- SF CLI org alias--name, -n- Name for code extension deployment--package-dir- Path to payload directory (REQUIRED - must be./payloadwhen running from project root)--package-version- Version string (default: 0.0.1)--description- Description of code extension
Optional Options:
--cpu-size- CPU size: CPU_L, CPU_XL, CPU_2XL (default), CPU_4XL--function-invoke-opt- Function invoke options (for function type)--network- Docker network (default: default)
After deployment:
- Navigate to Data Cloud in Salesforce UI
- Go to Data Transforms section
- Find your deployment by name
- Click "Run Now" to execute
- Schedule for recurring execution
Error Handling
Common Issues and Solutions
| Error | Solution |
|---|---|
command data-code-extension not found | sf plugins install @salesforce/plugin-data-codeextension |
datacustomcode CLI not found | pip install salesforce-data-customcode |
Python version mismatch | Use pyenv: pyenv install 3.11.0 && pyenv local 3.11.0 |
Cannot connect to Docker daemon | Start Docker Desktop |
No org found for alias | sf org login web --alias <org_alias> |
config.json not found | sf data-code-extension script scan --entrypoint ./payload/entrypoint.py |
DLO not found | Verify DLO exists (use getting-datacloud-schema skill), check spelling and __dll suffix |
Permission denied writing | Re-run scan, verify target DLO exists and is writable |
Deploy fails - wrong directory | Ensure --package-dir points to payload/ directory, not project root |
Best Practices
Development
- Always scan before testing — run scan after code changes
- Test locally first — use
runcommand before deploying - Use version control — git commit after each successful test
- Version your deployments — use semantic versioning (1.0.0, 1.1.0, etc.)
- Deploy from project root with
--package-dir ./payload
Performance
- CPU_L: Small datasets (< 1M records)
- CPU_2XL: Medium datasets (1M-10M records)
- CPU_4XL: Large datasets (> 10M records)
Security
- No hardcoded credentials — use SF CLI authentication only
- Validate input data — check for nulls and data types
- Limit write permissions — only grant necessary DLO/DMO access
Integration with Other Skills
Use with getting-datacloud-schema skill (CRITICAL for validation):
The getting-datacloud-schema skill is required for validating DLOs before testing code extensions.
Use with Datakit Workflow:
- Create DLO via code extension
- Map DLO to DMO using datakit workflow
- Use DMO in segments and activations
Command Reference
| Command | Purpose | Required Args |
|---|---|---|
script init | Create new script project | --package-dir |
function init | Create new function project | --package-dir |
script scan | Generate config | entrypoint file |
script run | Test locally | entrypoint file, --target-org |
script deploy | Deploy to Data Cloud | --target-org, --name, --package-dir, --package-version, --description |
Resources
- SF CLI Plugin: https://github.com/salesforcecli/plugin-data-code-extension
- Python SDK: https://github.com/forcedotcom/datacloud-customcode-python-sdk
- Data Cloud Docs: https://help.salesforce.com/s/articleView?id=sf.c360_a_intro.htm
- Python SDK PyPI: https://pypi.org/project/salesforce-data-customcode/
Notes
- Code extensions run in isolated Python 3.11 environment
- Docker is required only for deployment, not for local testing
- Use SF CLI authentication only (no separate credential files)
- Scan command auto-detects permissions from code
- Local run uses actual Data Cloud data (not mocked)
- Deployments are versioned and can be rolled back in UI
Related skills
More from forcedotcom/sf-skills and the wider catalog.
generating-apex
Primary Apex authoring skill for class generation, refactoring, and review. ALWAYS ACTIVATE when the user mentions Apex, .cls, triggers, or asks to create/refactor a class (service, selector, domain, batch, queueable, schedulable, invocable, DTO, utility, interface, abstract, exception, REST resource). Use this skill for requests involving SObject CRUD, mapping collections, fetching related records, scheduled jobs, batch jobs, trigger design, @AuraEnabled controllers, @RestResource endpoints, custom REST APIs, or code review of existing Apex.
generating-apex-test
Generate and validate Apex test classes with TestDataFactory patterns, bulk testing (251+ records), mocking strategies, assertion best practices, and disciplined test-fix loops. Use this skill when creating new Apex test classes, improving test coverage, debugging and fixing failing Apex tests, running test execution and coverage analysis, or implementing testing patterns for triggers, services, controllers, batch jobs, queueables, and integrations. Triggers on *Test.cls, *_Test.cls files, sf apex run test workflows, coverage reports, test-fix loops. Do NOT trigger for production Apex code (use generating-apex) or Jest/LWC tests.
generating-lwc-components
Lightning Web Components with PICKLES methodology and 165-point scoring. Use this skill when the user creates or edits LWC components, builds wire service patterns, or writes Jest tests for LWC. TRIGGER when: user creates/edits LWC components, touches lwc/**/*.js, .html, .css, .js-meta.xml files, or asks about wire service, SLDS, or Jest LWC tests. DO NOT TRIGGER when: Apex classes (use generating-apex), Aura components, or Visualforce.
generating-flow
Generate Salesforce Flows using the MCP tool execute_metadata_action. Use when the user asks to create, build, or generate a flow — including Screen, Autolaunched, Record-Triggered (before/after-save), Scheduled. Also trigger for flow-like requests such as \"when a record is created\", \"trigger daily at\", \"send an email when\", \"update the field when\", \"automate\", \"workflow\", or \"flow XML/metadata\". This is the only skill for Salesforce Flow generation.
querying-soql
SOQL query generation, optimization, and analysis with 100-point scoring. Use this skill when the user needs SOQL/SOSL authoring or optimization: natural-language-to-query generation, relationship queries, aggregates, query-plan analysis, and performance or safety improvements for Salesforce queries. TRIGGER when: user writes, optimizes, or debugs SOQL/SOSL queries, touches .soql files, or asks about relationship queries, aggregates, or query performance. DO NOT TRIGGER when: bulk data operations (use handling-sf-data), Apex DML logic (use generating-apex), or report/dashboard queries.
generating-custom-object
Use this skill when users need to create, generate, or validate Salesforce Custom Object metadata. Trigger when users mention custom objects, creating objects, object metadata, .object files, sharing models, name fields, or validation rules on objects. Also use when users say things like \"create a custom object\", \"generate object metadata\", \"set up an object for...\", or when they're troubleshooting object deployment errors especially around sharing models and Master-Detail relationships. Always use this skill for any custom object metadata work.