I'm using the Force.com Migration Tool for Ant more and more. I currently have several organizations at different API versions (release previews, for example). Is there a way to generate a complete package.xml file for an organization that would include (1) all of the metadata components that use '*' to subscribe to all items, in addition to (2) listing all specific items for component type where that's required (standard objects, reports, email templates, etc.)

I know that the Force.com IDE does this as part of the "Select Metadata" wizard, so I could use that process to refresh each of my projects, but I'm looking for something that could be included (for example) in an Ant script, to help me keep my organization snapshots up-to-date.


  • When you state that you have orgs in different versions, are you referring to the pre-release sandbox versions?
    – pchittum
    Jan 21, 2013 at 0:09
  • Yes, exactly -- and they have different metadata types available.
    – Benj
    Jan 21, 2013 at 2:25
  • Presumably there is a way to do this, as the "upgrade version" feature in the IDE does this. My guess is that it is calling describeMetadata and using the result to construct the new manifest file.
    – pchittum
    Jan 21, 2013 at 11:03

5 Answers 5


It'll take some heavy lifting, but you can do this with the metadata API or ANT.

Step 1 Figure out what components are available

Use a describeMetadata() call to get a list of all metadata component types that are available for retrieval. It'll return the name to use in your package.xml, as well as info about if it's stored in a folder. Unfortunately it does NOT return details about whether the particular metadata component type can be retrieved via the wildcard attribute. You might consider storing a list in your program of what can use the wildcard, or you could just specify the exact name for every instance of each metadata component type.

The Salesforce ANT library also has a a describeMetadata target that returns the same result in text form.

In both cases you can optionally pass in an API version.

Step 2 Retrieve folders for in-folder metadata types

For metadata that is stored in folders you'll need to know the folder before you can get a list of what metadata is in the org. You can do this with a listMetadata() call (supposedly you can do a retrieve call to, but that hasn't worked for me).

To list out the folders, add a "Folder" suffix to the foldered-metadata type, i.e. "DashboardFolder" for dashboard folders or "ReportFolder" for report folders, to get the metadata type and then do a listMetadata() call.

The Salesforce ANT library also has a listMetadata target that returns the same results in text form.

Step 3 List out components for each metadata type

For each component type returned in Step 1 that's not foldered use a listMetadata() call to get a list of all instances of that component in the target org. You could skip this for components that support wildcards, assuming you're storing which support that somewhere.

For foldered metadata types you'll need to make a list call for each folder.

Step 4 Build out your package.xml

At this point you'll have everything you'll need to build out a package.xml.

Step 5 Retrieve your data

Use your package.xml do to a retrieve.

Gotchas Max Retrieval Limit

One thing you'll likely run into if you're doing this with any client orgs is the max retrieval limit. To work around this you can have an intermediate process chunk your package.xml into smaller mini-retrieves. This is normally an issue when orgs have a lot of reports. This gist shows an example done with ruby (warning: ugly code!).

  • I did tried the same method which u mentioned, but it is too complicated to parse the received output. could you pls help me out to explain it more. Actually I am very new to ant scripting. I am currently using pre configured package.xml file for the components which are retrieved via *. and another package.xml where I have mentioned components which supports the folders. In case there is any change in the folder structure in the org, I ma planning to update this Package.xml manually.
    – GirishP
    Oct 18, 2013 at 12:26
  • @user3813, welcome to SFSE! If you're having trouble with parsing the describe metadata results my recommendation would be to ask a separate question with the specific parsing difficultly you are having or questions about ant scripting. As a Q&A site [SFSE] works best when there is a single question with a clear answer, rather than having multiple related discussions on the same question. That said, the manual approach sounds good to me until it gets onerous enough to warrant taking care of the parsing (ps I don't have a working implementation of this, would gladly share if I did) Oct 18, 2013 at 13:55

If you are using vs code there is an extention to build package.xml using point and click

Salesforce Package.xml generator extension for VS Code


enter image description here

Affiliation: I am the developer of this free to use extension


Here's a ready made Java JAR that you point to an org (through properties files), tell it what metadata types to go and look for, and it then goes off and inventories your org and builds a package.xml for you based on the types you've specified. Even has a handy-dandy feature allowing you to skip certain things based on a regular expression, so you can easily e.g. exclude managed packages, or some custom namespaces (say you prefix a bunch of things that belong together with CRM_) from the generated package.

So a comandline like this:

java -jar PackageBuilder.jar [-o <parameter file1>,<parameterfile2>,...] [-u <SF username>] [-p <SF password>] [-s <SF url>] [-a <apiversion>] [-mi <metadataType1>,<metadataType2>,...] [-sp <pattern1>,<pattern2>,...] [-d <destinationpath>] [-v]

will spit out a nice up-to-date package.xml for your ANT pleasure.

Disclaimer: I'm the author. Code may be dodgy in places where it deals with metadata types I haven't spent a lot of time testing with.


Try this online service to generate complete package.xml: https://packagebuilder.herokuapp.com

  • 1
    Did you take some part in writing this service?
    – Adrian Larson
    Nov 5, 2018 at 13:37
  • No. I'm just using that sometime.
    – Jozef H
    Nov 13, 2018 at 10:27

The package.xml that is used in the Force.com IDE is the same as the one you would use in the Force.com migration tool. So if you refresh one of your projects with everything, you should be able to grab that package.xml and massage it to what you want and then use it to perform a retrieve.

You can open it in the Force.com ide itself and copy/paste the xml to another file. Or if you just want to grab it from the file system, simply find your Eclipse workspace. From there navigate to your project folder's src directory. You will then find the package.xml there.

  • 4
    as stated in my question, I know that I could use Force.com IDE to create this package.xml - but I'm looking for a way of refreshing the manifest without using the IDE user interface.
    – Benj
    Jan 21, 2013 at 0:53
  • Sorry...I misunderstood. I figured doing it once for an org would allow you to copy that package.xml for use in other orgs.
    – pchittum
    Jan 21, 2013 at 10:13
  • Yeah - that's what I'm doing now, but it's imperfect because of different api versions, different standard objects (e.g. whether or not chatter/content/etc. are enabled) and different reports and so on. But it's getting me by for the time being.
    – Benj
    Jan 21, 2013 at 14:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .