What does “version” do in package.xml in Salesforce?

If you have worked with package.xml in Salesforce to retrieve or deploy components, you have seen the “<version></version>” tag. Do you know what exactly it does?

Version determines which version of Metadata API Salesforce will use to retrieve or deployment your components. And that will mean that only those properties will be retrieved or deployed that was available in that version.

Here is a package.xml file that I used to retrieve the same component (one custom object and one custom profile) with different versions. The Org that I used is currently on Winter ’22 Release of Salesforce (i.e. version 53.0)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="">
        <members>AA System Administrator</members>

Salesforce Metadata Types that Do Not Support Wildcard Characters in Package.xml

When we want to retrieve or deploy metadata to a Salesforce Org, we use package.xml either with ANT command or using SFDX. And when retrieving metadata from a Salesforce org, it is quite common to use wildcard character asterisk (*) to retrieve everything of that metadata type.

For example, the following is used in package.xml to retrieve metadata about all custom objects.

<?xml version=1.0 encoding=UTF-8 standalone=yes?>
<Package xmlns=>

Step By Step Guide to Using Restriction Rules in Salesforce

Restriction Rules in Salesforce

Traditionally, to control the visibility of records in Salesforce, we used to start with the most restrictive setting (i.e. setting OWD to Private for an object) and then opening up the access using various features like role hierarchy, sharing rules, teams etc. 

Consider the following diagram. Before Restriction rules, we started with the most restrictive setting and then opened up access using various features.

How To Bypass Automations & Validations in Salesforce for Mass DML Operations

In Salesforce, it is not uncommon to mass insert, update or delete records from time to time. This may be required to onboard new business units, departments or applications, fix bugs, patch existing records with certain values, accommodate changes in data model, archive and delete data etc.

But as we process data in bulk, validation rules and automation that are defined in Salesforce kicks in. This not only slows down the DML operation but may also lead to undesired processing like triggering emails to internal and external users, sending interface messages to backend systems and cause process and/or data integrity issues.

Scroll to Top