Workflow for Data Cloud Second-Generation Managed Packages
Creating and packaging a Data Cloud app is similar to creating and packaging any app using second-generation managed packaging (2GP), but there are a few key differences in the process.
You still use the Salesforce CLI commands and scratch orgs, but in Data Cloud, the features that you want to include must be added to a data kit first. Then you retrieve that metadata into a Salesforce DX project and move that project to a GitHub repository. Once there, other developers can clone it, deploy the data kit metadata to their scratch org, and continue to make customizations.
When development is complete, you create a version, package it up, and send it out into the world.
The basic 2GP workflow includes these steps. See specific topics for details about each step.
- Get a Developer Edition org that has Data Cloud licenses, and configure it to be your Dev Hub org. This Developer Edition org is the org that you use to manage scratch orgs. For Salesforce ISV and OEM partners, this org is most likely your Partner Business Org (PBO). Contact the Partner Community for further assistance. See Enable Dev Hub and Second Generation Managed Packaging.
- Enable second-generation managed packaging in your Dev Hub org. See See Enable Dev Hub and Second-Generation Managed Packaging.
- Sign up for a Developer Edition org to use as a namespace org, and specify a namespace. See Create and Register Your Namespace for Second-Generation Managed Packages.
- From your Dev Hub org, register the namespace that you created. See Link a Namespace to a Dev Hub Org.
-
Before you create and work with a project, be sure that you have all the development tools installed.
- Install VS Code. See Install Salesforce Extensions Visual Studio Code.
- Install the Salesforce CLI. See Install Salesforce CLI.
- Install the Salesforce Extension Pack (Expanded) for VS Code. See Salesforce Extension Pack (Expanded).
- Enable the org shape in the Dev Hub org so that you can create a scratch org that has the same org shape as the Dev Hub org. The scratch orgs inherit the Data Cloud licenses and perms of the Dev Hub org. See Enable Org Shape for Scratch Orgs. For more information on org shape and scratch orgs, see Create a Scratch Org Based on an Org Shape.
- From the CLI, authorize the Dev Hub org. See Authorize an Org Using a Browser.
- From the CLI, create the org shape. See Create and Manage Org Shapes.
- Create a project. See Create a Salesforce DX Project.
- In the
sfdx-project.json
file, specify the namespace using the namespace attribute. For example:"namespace":"exp-mgr"
- In the
sfdx-project.json
file, specify the login URL, which is https://login.salesforce.com for production. - Verify that the
project-scratch-def.json
file has the correct values for orgName and sourceOrg. The sourceOrg value is the org ID of the Dev Hub org. - Update the
.forceignore
file, and add a line that contains the string**ssot**
. This modification ensures that any components prefixed by thessot
namespace are ignored and the metadata for these components isn’t retrieved from the scratch org. - Create a
package.xml
file that contains the Data Cloud features. Copy this code into thepackage.xml
file.
- From the CLI, create a scratch org using the org shape that you just created. See Create Scratch Orgs. This scratch org is the publisher or source org where you create the Data Cloud elements and add them to a data kit.
- Set the scratch org to be the default org.
- Issue the
sf org open
command to open the scratch org UI. Verify that Data Cloud is enabled in the scratch org by navigating to Data Cloud Setup. If you see green checkmarks, then Data Cloud is provisioned.
- In the scratch org, create your Data Cloud elements: data streams, data mappings, calculated insights, streaming or batch data transforms, and so on.
- Create a data kit, and add the Data Cloud features that you created to that data kit. See Create a Data Kit.
- From the CLI, use the command
sf project retrieve start --manifest package.xml
to retrieve the data kit metadata from the scratch org into the project that you created. See Retrieve Source From the Scratch Org to Your Project. After this command completes, you see new project folders that contain the data kit metadata. - At this point, you can upload the entire project to GitHub or any source control system. Another developer can then download that project, deploy the data kit into their scratch org, and modify it. For example, that developer can add a new data stream to the data kit. This workflow enables multiple developers to work on the same data kit.
- This optional step only applies when multiple developers are working with the same data kit. For example, a second developer downloads the project from GitHub. The first step is to deploy the data kit and its metadata from the project into that developer’s scratch org.
- Use the command
sf project deploy start --manifest package.xml
to start the deployment. See project deploy start. - After the data kit is deployed to the second scratch org, open the scratch org to see the data kit and all of its data stream bundles, data models, calculated insights, and so on.
- The data kit is installed, but you still must deploy the data streams, data models, calculated insights, and all of the data kit elements into the second scratch org. See Deploy a Data Stream from a Data Kit.
- The second developer can then create a data stream in their scratch org, add it to a data kit, retrieve the metadata into their project, and then upload that project to GitHub for another developer to work on.
- From the CLI run the
sf package create
command to package the data kit. See package create. This process creates a beta package, which can only be installed in a scratch org. - In the
sfdx-project.json
file, add a dependency to the ssot package by adding this code. You can find the latest ssot package ID on the Partner Community site. Before you can create a package version, you must specify the ssot dependency.
- Create the package version. See package create.
- When you have a package version that’s ready to distribute, promote that package to a released version. The released version can be installed in a production org. See Release a Second-Generation Managed Package.
- Second-Generation Managed Packaging Developer Guide: Second-Generation Managed Packages
- Data Cloud Developer Guide: Packages and Data Kits