Identify Packageable Components in Data Cloud

Learning Objectives

After completing this unit, you’ll be able to:

Explain the difference between unmanaged and managed packages.
Identify when to use a data kit in Data Cloud.
Learn about application lifecycle management (ALM) and its application to Data Cloud.

Data Cloud Configuration

Salesforce Data Cloud is an extensively-designed customer data platform built on Salesforce. In other words, it was built to allow for the development and sharing of key capabilities and functionality. In this badge, we cover the Data Cloud functionality that is packageable using data kits and Package Manager. We are ready to help you build and share Data Cloud configuration. After all, sharing is caring.

Common Terms and Concepts

Let’s start by covering some important terms and concepts related to extensibility.

Metadata

Metadata is data that describes other data. So meta. Data Cloud metadata relates to the fields, configurations, and code that make up your Data Cloud environment. Metadata can be imported into Salesforce orgs, modified in the product interface, or edited via the Salesforce Metadata API. Learn more about Metadata API in the Metadata API Developer Guide.

Salesforce Package

A package is a container of custom objects and metadata created with Package Manager. Creating a package provides you with an installable artifact that can be installed on one or many orgs, and can be shared with other Salesforce users. Two types of packages can be used across Salesforce functionality: unmanaged and managed. Unmanaged packages can’t be upgraded, while managed packages support versioning and push upgrades for automation.

Data Kit

A data kit is a portable and customized bundle of packageable metadata, created within Data Cloud. This can be done without writing any line of code directly from the UI. Data kits allow you to streamline the package creation and installation process. Data Cloud objects, such as metadata and relationships, can be wrapped together with a few easy clicks. Once a data kit is created, you use Package Manager to complete the setup as a managed or unmanaged package.

Packageable Components in Data Cloud

Now let’s review some common functionality that can be packaged for use with Data Cloud. We review the functionality for both standard packages and data kit packages. Visit the Data Cloud Extensibility Readiness Matrix documentation see a complete list of Data Cloud configuration elements that you can deploy.

Data Streams: CRM, Amazon S3, and B2C Commerce data streams can be packaged within a data kit. S3 data streams with associated mapping can be packaged for both standard and custom data models.
Calculated Insights: Calculated Insights are Data Cloud definitions and calculations that aid in segmentation. The SQL components can be included in a standard package.
Mapped Data Model: If a data stream is added to a data kit, the data models that it’s mapped to are automatically added and auto-populated to prepare for segmentation.

Once these components are added to a data kit, they can be packaged together in Package Manager and deployed in another org.

Application Lifecycle Management

So, why use packaged components? Packages and data kits are typically used for configuration testing within the process of application lifecycle management (ALM). ALM is a fast, efficient, and trusted path for building applications using various environments.

Application Lifecycle Management stages: Plan, Code, Merge & Test, Test & UAT, and Release.

Developers can build in a development org, create data kits and package elements from that org, and then deploy them in a test org. Once fully tested and confirmed, the same (or updated) data kits can then be deployed in a production org. This is key to Data Cloud, since mapping and modeling your data correctly is required for Data Cloud features like identity resolution and segmentation.

Let’s review the typical environment setup. As we mentioned, the ALM allows for developers to build in one org, test in another, and release to a production org.

Chart for environments: Developer, Test, Production.

In fact, to use standard packages you need at least two environments: one org to create the package and another org to install it. While you can skip having a test org, it’s best practice to fully test your configuration in a test org, and then make any needed adjustments back in the developer org. Then you can repeat your process before deploying a final package in a production org.

Discuss your Data Cloud org structure with your account admin or account executive.

Now that you understand the why, in the next unit, we cover the how. Get ready to create, upload, and install a data kit in Data Cloud.