Sample package.xml Manifest Files

Standard Objects

This sample package.xml manifest file illustrates how to work with the standard Account object. Retrieving or deploying a standard object includes all custom and standard fields except for standard fields that aren’t customizable. All custom fields are supported. Only standard fields that you can customize are supported, that is, standard fields to which you can add help text or enable history tracking or Chatter feed tracking. Other standard fields aren't supported, including system fields (such as CreatedById or LastModifiedDate) and autonumber fields.

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>Account</members>
5        <name>CustomObject</name>
6    </types>
7    <version>39.0</version>
8</Package>

Note how you work with the standard Account object by specifying it as a member of a CustomObject type. However, you cannot use an asterisk wildcard to work with all standard objects; each standard object must be specified by name.

All Custom Objects

This sample package.xml manifest file illustrates how to work with all custom objects.

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>*</members>
5        <name>CustomObject</name>
6    </types>
7    <version>39.0</version>
8</Package>

This manifest file can be used to retrieve or deploy all custom objects. This does not include all standard objects.

Standard Picklist Fields

In API version 38.0 and later, the StandardValueSet type represents standard picklists. Picklists are no longer represented by fields as in earlier versions. This sample package.xml represents the Industry standard picklist as a StandardValueSet type.

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>Industry</members>
5        <name>StandardValueSet</name>
6    </types>
7    <version>39.0</version>
8</Package>

The Industry standard value set corresponds to the Account.Industry or Lead.Industry field in API version 37.0 and earlier. This example shows a package.xml sample for the Account.Industry picklist.

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>Account.Industry</members>
5        <name>CustomField</name>
6    </types>
7    <version>37.0</version>
8</Package>

Note the objectName.picklistField syntax in the <members> field where objectName is the name of the object, such as Account, and picklistField is the name of the standard picklist field, such as Industry.

This next package.xml sample represents opportunity team roles in API version 38.0 and later. Specify opportunity team roles as a SalesTeamRole standard value set. Opportunity team roles have the same picklist values as the account team roles.

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>SalesTeamRole</members>
5        <name>StandardValueSet</name>
6    </types>
7    <version>39.0</version>
8</Package>

The SalesTeamRole standard value set corresponds to one of these field names in API version 37.0 and earlier: OpportunityTeamMember.TeamMemberRole, UserAccountTeamMember.TeamMemberRole, UserTeamMember.TeamMemberRole, and AccountTeamMember.TeamMemberRole. Opportunity team roles are represented in this sample package.xml as the OpportunityTeamMember.TeamMemberRole field.

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>OpportunityTeamMember.TeamMemberRole</members>
5        <name>CustomField</name>
6    </types>
7    <version>37.0</version>
8</Package>

To learn about the names of standard value sets and how they map to picklist field names, see StandardValueSet Names and Standard Picklist Fields.

Custom and Standard Fields

This sample package.xml manifest file illustrates how to work with custom fields in custom and standard objects and standard fields in a standard object.

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>MyCustomObject__c.MyCustomField__c</members>
5        <name>CustomField</name>
6    </types>
7    <types>
8        <members>Account.SLA__c</members>
9        <members>Account.Phone</members>
10        <name>CustomField</name>
11    </types>
12    <version>39.0</version>
13</Package>

Note the objectName.field syntax in the <members> field where objectName is the name of the object, such as Account, and field is the name of the custom or standard field, such as an SLA picklist field representing a service-level agreement option. The MyCustomField custom field in the MyCustomObject custom object is uniquely identified by its full name, MyCustomObject__c.MyCustomField__c. Similarly, the Phone standard field in the Account standard object is uniquely identified by its full name, Account.Phone.

All custom fields are supported. Only standard fields that you can customize are supported, that is, standard fields to which you can add help text or enable history tracking or Chatter feed tracking. Other standard fields aren't supported, including system fields (such as CreatedById or LastModifiedDate) and autonumber fields.

List Views for Standard Objects

The easiest way to retrieve list views for a standard object is to retrieve the object. The list views are included in the retrieved component. See Standard Objects.

You can also work with individual list views if you do not want to retrieve all the details for the object. This sample package.xml manifest file illustrates how to work with a list view for the standard Account object.

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>Account.AccountTeam</members>
5        <name>ListView</name>
6    </types>
7    <version>39.0</version>
8</Package>

Note the objectName.listViewUniqueName syntax in the <members> field where objectName is the name of the object, such as Account, and listViewUniqueName is the View Unique Name for the list view. If you retrieve this list view, the component is stored in objects/Account.object.

Packages

To retrieve a package, set the name of the package in the packageNames field in RetrieveRequest when you call retrieve(). The package.xml manifest file is automatically populated in the retrieved .zip file. The <fullName> element in package.xml contains the name of the retrieved package.

If you use an asterisk wildcard in a <members> element to retrieve all the components of a particular metadata type, the retrieved contents do not include components in managed packages. For more information about managed packages, see the ISVforce Guide.

The easiest way to retrieve a component in a managed package is to retrieve the complete package by setting the name of the package in the packageNames field in RetrieveRequest, as described above. The following sample package.xml manifest file illustrates an alternative to retrieve an individual component in a package.

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>myns__MyCustomObject__c</members>
5        <name>CustomObject</name>
6    </types>
7    <version>39.0</version>
8</Package>

Note the namespacePrefix__objectName syntax in the <members> field where namespacePrefix is the namespace prefix of the package and objectName is the name of the object. A namespace prefix is a 1 to 15-character alphanumeric identifier that distinguishes your package and its contents from other publishers’ packages. For more information, see “Register a Namespace Prefix” in the Salesforce Help.

Security Settings

This sample package.xml manifest file illustrates how to work with an organization’s security settings. You specify Security in the <members> element and Settings in the name element when retrieving the SecuritySettings component type.

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>Security</members>
5        <name>Settings</name>
6    </types>
7    <version>39.0</version>
8</Package>

Assignment Rules, Auto-response Rules, Escalation Rules

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>Case</members>
5        <members>Lead</members>
6        <name>AssignmentRules</name>
7    </types>
8    <version>39.0</version>
9</Package>

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>Case.samplerule</members>
5        <members>Lead.newrule</members>
6        <name>AssignmentRule</name>
7    </types>
8    <version>39.0</version>
9</Package>

Sharing Rules

In API version 33.0 and later, you can retrieve and deploy sharing rules for all standard and custom objects. This sample package.xml manifest file illustrates how to work with an organization’s sharing rules, which includes retrieving a specific criteria-based sharing rule for the lead object, retrieving all ownership-based sharing rules for all objects, and retrieving all territory-based sharing rules for the account object.

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>Lead.testShareRule</members> 
5         <name>SharingCriteriaRule</name>
6    </types>
7    <types>
8        <members>*</members> 
9        <name>SharingOwnerRule</name>
10    </types>
11    <types>
12        <members>Account.*</members>
13        <name>SharingTerritoryRule</name>
14    </types>
15    <version>33.0</version>
16</Package>

Managed Component Access

When retrieving and deploying managed component permissions, specify the namespace followed by two underscores. Wildcards are not supported.

For example,  let’s say you install a managed package with the namespace MyNamespace and the custom object JobRequest__c. To set object permissions for JobRequest__c in the package to the custom profile MyProfile, you would add the following to the .profile file.

To deploy:

1<objectPermissions>
2    <allowCreate>true</allowCreate>
3    <allowDelete>true</allowDelete>
4    <allowEdit>true</allowEdit>
5    <allowRead>true</allowRead>
6    <viewAllRecords>false</viewAllRecords>
7    <modifyAllRecords>false</modifyAllRecords>
8    <object>MyNamespace__JobRequest__c</object>
9</objectPermissions>

To retrieve:

1<types>
2    <members>MyNamespace__JobRequest__c</members>
3    <name>CustomObject</name>
4</types>
5<types>
6    <members>MyProfile</members>
7    <name>Profile</name>
8</types>

When retrieving permission sets and profiles, make sure that you also retrieve any components that are related to the permissions and settings. For example, when retrieving app visibilities, you must also retrieve the associated app, and when retrieving object or field permissions, you must also retrieve the associated object.