Get to Know the Package.xml Manifest

Learning Objectives

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

• Define metadata.
  
• Identify and explain the different types of metadata.
  

A Different Approach

Deploying and updating metadata components is a normal part of your day when you’re creating apps on the Salesforce Platform. With all of the packaging types there are today, deciding which process to follow or which terminal command to run can sometimes be a challenge. You might be migrating profile permissions into defined permission sets, or maybe just grabbing a single metadata component for a deploy. Knowing how to use package.xml files to manage the metadata in your org is an essential tool for your toolbox. 

Before we dive into creating a package.xml file, let’s take a moment to understand what metadata components are. 

Metadata Components

A metadata component is an instance of a metadata type. Metadata types are the general classification for metadata components. For example, CustomObject is a metadata type for standard and custom objects. In the example below, the MyCustomObject__c custom object (a metadata component) is an instance of the CustomObject metadata type.

<types>
   <members>MyCustomObject__c</members>
   <name>CustomObject</name>
</types>

What Is Metadata?

Metadata are the assets in your org (assets being objects, tabs, classes, etc). These metadata assets are also called metadata components. For each metadata component you reference in the package.xml file (such as a custom tab for a custom object, Sticker__c), you receive a coded file. This coded file defines how the component functions within the database. To call on the metadata components in your package.xml, you reference them by their metadata type. 

In the package.xml example below, the metadata types CustomObject and CustomTab are pointing to two metadata components. 

• The custom object’s API name is Sticker__c.
  
• The custom tab is assigned to that custom object, so its name is also Sticker__c.
  

After retrieving metadata using the above package.xml, the system returns the .xml files that define how the component works. Below is an example of the xml file for the custom tab that is associated with the Sticker__c custom object.

There’s no need to edit these files; however, it’s important to understand how each of these metadata components relate to one another.

Different Types of Metadata Components

There are three different kinds of metadata components: simple, compound, and complex. As you work with various kinds of metadata components in your Salesforce org, it’s important to know and understand how each component works with the next. 

• Simple—A single file. This type of metadata can be retrieved and deployed on its own without requiring other metadata components.
  
• Compound—Two files that call one another. For example, an Apex class or a trigger includes two files: the class file and the xml (-meta.xml) file that makes the class function within the org.
  
• Complex—Files that may contain multiple named components, depending on which components are being pulled. For example, a custom object may contain multiple custom fields and corresponding components that rely on one another.
  

Let’s look at an example of a complex metadata component type. Let’s say you are building a sticker-tracking application and have created a custom object. Your object may have custom fields, which can be both simple and complex metadata types. When deploying a complex metadata component, you may need to deploy any dependent components with it.

Metadata Tools

Salesforce has a variety of tools you can use to work with the metadata in your org, such as change sets or the Salesforce command-line interface (CLI). When you’re deploying metadata, each of these tools serves a purpose and is very useful, depending on what you are aiming to accomplish. Package.xml is just another handy-dandy tool in your toolbox. 

Package.xml is also useful if you are creating an unmanaged package, or if you want to grab only specific metadata components to deploy. If you don’t have any experience with these tools, that’s OK! For this project, you build an unmanaged package that will be used for the deployment and use the Salesforce CLI to do all of the heavy lifting. 

Next, let’s explore the language that makes package.xml magical.

Behind the Curtain of Package.xml

The package.xml manifest is coded in XML language. This language tells the system interesting things like which specific metadata components to retrieve, deploy, or update. When we think of coding languages, most of the time we tend to think of object-oriented programming languages such as Apex, Java, or JavaScript. These languages bring some sort of action to the components you’re working with, like having a button execute a class, or sending an email. The XML language operates a bit differently. 

What Is XML?

XML (Extensible Markup Language) is a text-based language that is used to identify, organize, and migrate metadata components. When working with XML and Salesforce metadata, (remember, “metadata” is referring to the components inside your org), you identify specific components in the XML file. XML file is commonly referred to as a “package.xml manifest”. This manifest contains a collection of metadata components and identifies them by their application programming interface (API) names, listing every component by type and corresponding with each metadata file. 

Before you start writing the package.xml manifest, let’s take a look at how to structure the file and what API to use.

Resources

• Salesforce Metadata API Developer Guide: Package.xml Sample Manifest
• Salesforce Metadata API Developer Guide: Metadata Types