I'm trying to get my head around the "Force.com Migration Tool". I'm using the Force.com IDE in Eclipse and this has provided me with a package.xml. I have all Metadata Components selected.

I've taken the example ant retrieve/deploy scripts that come with the Force.com Migration Tool download, and entered my own credentials. I've confirmed that I can deploy changes to my developer org.

Here's the deploy target:

<target name="deployCode">
  <sf:deploy username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" maxPoll="${sf.maxPoll}" deployRoot="src">

Probably not that unusual.

When I run this command, which takes code pulled from a sandbox and puts it onto an empty developer org, I get the following errors:


To be honest I don't know what this is telling me.

Is it reasonable to take the package.xml generated by the IDE? Are there types or members that should not be included in a package.xml use for deployment?

Any help appreciated.

  • I have found retrieving components via package.xml to be troublesome & tedious to maintain, so we have switched to using unmanaged packages in the source org. Simply populate the package with the components to be migrated, then retrieve using the package name, not an xml file, and then deploy as normal. As for the errors you're getting, most of them looking to be org. setting related - Account Teams etc. etc. Jun 12, 2014 at 10:58
  • But I have to have a package.xml to deploy. Here's what happens if I try and deploy without a package.xml in the "deployRoot" directory: 1. package.xml -- Error: No package.xml found
    – powlo
    Jun 12, 2014 at 11:39
  • Yes but when you retrieve the unmanaged package a package.xml will be included, so you don't have to use one from Eclipse etc. Jun 12, 2014 at 11:40

2 Answers 2


The error log shows a number of errors in the metadata you're trying to deploy through the Metadata API which the Force.com Ant Migration Tool ultimately calls. My hunch is that a full save to server from Force IDE would get the same errors.

One thing I've noticed about deployment logs is that you can often ignore the massive number of duplicate lines. For example, the following error appears all over your log:

Error: Required field is missing: type

It's likely that a previous failure is causing this error and fixing the other failures will make this one go away. So, going with that strategy, there are a few errors you need to fix in the metadata files to get the deployment to pass:

[sf:deploy] 1.  settings/Account.settings -- Error: You cannot disable account teams using the Metadata API.  Your system administrator can disable account teams from the Account Team Setup page.

Account Teams are not supported for deployment through the Metadata API: http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_unsupported_types.htm

[sf:deploy] 2.  objects/AccountContactRole.object -- Error: ControlledByParent is not a valid sharing model for AccountContactRole

Adjust the sharing model of AccountContactRole.object or if you didn't make any customizations to it, delete the file locally so it's not a part of your deployment.

[sf:deploy] 3.  objects/Site.object -- Error: Entity cannot be untracked.

This is likely due to the same issue with the same fix as discussed here: https://developer.salesforce.com/forums/ForumsMain?id=906F00000008k09IAA

[sf:deploy] 163.  objects/Contract.object (Contract.APXTConga4__Conga_Mail_Merge) -- Error: Cannot create a new component with the namespace: APXTConga4.  Only components in the same namespace as the organization can be created through the API (line 235, column 15)
[sf:deploy] 171.  objects/Solution.object (Solution.APXTConga4__Conga_Mail_Merge) -- Error: Cannot create a new component with the namespace: APXTConga4.  Only components in the same namespace as the organization can be created through the API (line 120, column 15)

These errors indicate that you're trying to deploy metadata which comes from the APXTConga4 package. You can only deploy managed page components by installing the managed package. There is a trick you can do via the migration tool to install managed packages into the org as a separate deployment but covering that is beyond this question.

Edit the offending objects and remove any metadata starting with APXTConga4__

Finally, I wanted to point to another option I've been working with lately. You can create an unmanaged package in your sandbox org (Setup -> Create -> Packages) and then add all the custom code you want to migrate to it. Then you can use Ant to pull down only the metadata you chose to include in that package. This approach helps you avoid a lot of the issues you're seeing as it doesn't pull down anything from standard salesforce or installed packages, only the code you explicitly tell it to include. I plan to write a blog post on this approach soon, but you can get some more details from this answer I posted a few months back:

Using sf:bulkRetrieve do not fetch metadata components associated with a managed package


The Error: Required field is missing: type seems to be related to deploying from a Summer '14 org to a Spring '14 org.

I have experienced similar errors in recent deployments that contain no other deployment errors, so at least that error is not due to other failures.

  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post.
    – dphil
    Jun 13, 2014 at 17:37
  • I have rephrased my response to emphasize the explanation about org version discrepancies.
    – Mike Ginou
    Jun 13, 2014 at 17:45
  • Possibly true, since this is what I'm doing.
    – powlo
    Jun 16, 2014 at 16:43

You must log in to answer this question.

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