data360-code-extension-generate
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.
- Installs
- 5K
- Last 24h
- +8
- Trending rank
- #9829
- Security
- Pass
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/forcedotcom/sf-skills --skill data360-code-extension-generate- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads data360-code-extension-generate automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
Security audits
Independent scans of the skill's instructions and bundled files.
SKILL.md
The instructions your agent reads when the skill is triggered.
data360-code-extension-generate 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-code-extension -
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 data360-schema-get 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-code-extension |
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 data360-schema-get 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 data360-schema-get skill (CRITICAL for validation):
The data360-schema-get 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
FAQ
What does the data360-code-extension-generate skill do?
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.
How do I install data360-code-extension-generate?
Run npx skills add https://github.com/forcedotcom/sf-skills --skill data360-code-extension-generate in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/data360-code-extension-generate/ (personal) or .claude/skills/data360-code-extension-generate/ (project).
Which AI agents can use data360-code-extension-generate?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is data360-code-extension-generate safe to install?
Security partners have reviewed it: Gen Agent Trust Hub passed; Socket passed; Snyk passed. As with any skill, read the SKILL.md and bundled scripts before installing.
Who maintains data360-code-extension-generate?
It is published by forcedotcom in forcedotcom/sf-skills. It has 4,955 recorded installs.
More from forcedotcom/sf-skills
platform-apex-generate
forcedotcom/sf-skills
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.
platform-apex-test-generate
forcedotcom/sf-skills
Use to generate and validate Apex test classes with TestDataFactory patterns, bulk testing (251+ records), mocking, assertions, and disciplined test-fix loops. Use when creating Apex test classes (for triggers, services, controllers, batch jobs, queueables, and callouts), improving coverage, debugging or fixing failing Apex tests, or running test/coverage analysis. Triggers on Test.cls files, sf apex run test, coverage reports. Do NOT trigger for production Apex (use platform-apex-generate) or Jest/LWC tests.
platform-apex-test-run
forcedotcom/sf-skills
Apex test execution, coverage analysis, and test-fix loops with 120-point scoring. Use when the user runs Apex tests, checks code coverage, fixes failing tests, or touches Test.cls / Test.cls files. DO NOT TRIGGER when writing Apex production code (use platform-apex-generate), Agentforce agent testing (use agentforce-test), or Jest/LWC tests (use experience-lwc-generate).
platform-apex-logs-debug
forcedotcom/sf-skills
Salesforce debug log analysis and troubleshooting with 100-point scoring. TRIGGER when: user analyzes debug logs, hits governor limits, reads stack traces, or touches .log files from Salesforce orgs. DO NOT TRIGGER when: running Apex tests (use platform-apex-test-run), generating or fixing Apex code (use platform-apex-generate), or Agentforce session tracing (use agentforce-observe).
platform-soql-query
forcedotcom/sf-skills
Use when the user needs SOQL/SOSL authoring or optimization: natural-language-to-query generation, relationship queries, aggregates, query-plan/selectivity analysis, and performance or safety improvements. TRIGGER when the user writes, optimizes, or debugs SOQL/SOSL, touches .soql files, or asks about relationship queries, aggregates, or query performance. DO NOT TRIGGER for bulk data operations (use platform-data-manage), Apex DML logic (use platform-apex-generate), or report/dashboard queries.
platform-metadata-deploy
forcedotcom/sf-skills
Salesforce DevOps automation using sf CLI v2. TRIGGER when: user deploys metadata, validates a deploy or does a dry-run, deploys to a Production org, quick-deploys a validated job ID, ships/promotes to prod, creates/manages scratch orgs or sandboxes, sets up CI/CD pipelines, or troubleshoots deployment errors with sf project deploy. DO NOT TRIGGER when: writing Apex code, building LWC components (use experience-lwc-generate), creating metadata definitions (use platform-custom-object-generate), deleting metadata from an org (use platform-destructive-deploy), or querying org data (use platform-data-manage).
Popular devops & cloud skills
microsoft-foundry
microsoft/azure-skills
Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure
azure-diagnostics
microsoft/azure-skills
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.
azure-prepare
microsoft/azure-skills
Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.
azure-ai
microsoft/azure-skills
Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.
azure-deploy
microsoft/azure-skills
Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.
azure-validate
microsoft/azure-skills
Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.