developing-datacloud-code-extension

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.

608stars215forksUpdated 6/25/2026

Data Science & ML DevOps & CI/CD #data-engineering #deployment #sf-cli #data-cloud #python #salesforce

Security Assessment

Safe(100/100)

Security Score100/100

About developing-datacloud-code-extension

A complete, phased workflow for building, testing, and shipping custom Python code extensions to Salesforce Data Cloud using the SF CLI plugin (@salesforce/plugin-data-codeextension). Code extensions let developers write Python transformations that read from and write to Data Lake Objects (DLOs) and Data Model Objects (DMOs), supporting both script-based batch transformations and function-based real-time processing. The workflow walks through five operations: init to scaffold a project, scan to detect required permissions and generate config.json, run to test locally against an authenticated org, and deploy to push the extension to Data Cloud for scheduled or on-demand execution.

Use it when creating a new code extension project, validating transformation logic locally, scanning code for the permissions it needs, or deploying a finished extension. The skill front-loads a prerequisites check: SF CLI with the plugin installed, Python 3.11, the salesforce-data-customcode SDK, Docker running (deploy only), and an authenticated org. It stresses directory context throughout - init runs from the parent directory while scan, run, and deploy run from the project root, and the deploy command's --package-dir argument must point at the generated payload directory rather than the project root.

Mechanically, transformations are written in payload/entrypoint.py using the datacustomcode Client (read_dlo, read_dmo, write_to_dlo, write_to_dmo) or a FunctionClient for real-time transforms. A dedicated pre-test phase has you validate DLO schemas - confirming every DLO and field name referenced in code actually exists in the target org (case-sensitive) - by leaning on the companion getting-datacloud-schema skill before running. The deploy step exposes options for naming, versioning, description, CPU size (CPU_L through CPU_4XL), and Docker network, after which the extension appears under Data Transforms in the Salesforce UI for execution or scheduling. A troubleshooting table maps common errors to fixes for missing plugins, Python version mismatches, Docker connectivity, and org authentication.

FAQ

What prerequisites must be in place before running code extension commands?

The SF CLI with the data-codeextension plugin installed, Python 3.11, the salesforce-data-customcode SDK, an authenticated org, and Docker running for the deploy step. The skill provides verification commands for each.

What is the difference between script-based and function-based code extensions?

Script-based extensions are batch transformations initialized with 'sf data-code-extension script init', while function-based extensions handle real-time processing and use 'function init'. Scripts use a Client, functions use a FunctionClient.

Why does the deploy command require --package-dir ./payload?

The init command creates a payload directory containing entrypoint.py and config.json, and deploy must point to that payload directory rather than the project root. Pointing it elsewhere causes the deployment to fail.

How do I confirm my transformation references valid DLOs and fields before testing?

Run the scan to populate config.json, then use the getting-datacloud-schema skill to verify each DLO exists and that field names match exactly (case-sensitive) for both read and write permissions before running locally.

What CPU sizes are available when deploying an extension?

The --cpu-size option accepts CPU_L, CPU_XL, CPU_2XL (the default), and CPU_4XL. Other deploy options include package name, version, description, and Docker network.