I am very familiar in using ANT Migration tool for deployments.

Can someone briefly explain different real time scenarios when we should go for Force.com IDE vs Change Sets.

2 Answers 2


Changesets are useful when you need a history of what was done or if the user in the sandbox does not have access to production. They are also useful when you want to send profile permissions in the deployment along with the changeset.

The IDE will deploy code ad hoc but I do not believe it will migrate profile permissions at the same time. Also, if the user does not have access to the destination org it obviously will not work.

  • The IDE will deploy permissions; you need to include the field as well as the permission in the deployment. I would assume the same is true for Changesets, never tried that though.
    – zainogj
    Feb 8, 2014 at 19:10
  • Good to know. Just never tried
    – Eric
    Feb 10, 2014 at 2:06

Some additional notes to the above:

If your sandbox is on Vx+1 and PROD is on Vx as is typical for about three months of every year, you will most likely be stymied trying to deploy changesets as the Changeset UI prevents this in many (all?) cases. Force.com IDE and Ant aren't affected by this provided your new components were defined at Vx.

Changeset UI can be tedious to use, especially for custom fields if you have lots of them. It is easy to forget something unless you keep separate and perfect records

Eclipse IDE will tell you which elements in your project are different from your target org through a red-yellow-green color coding scheme so if you've kind of lost track of what you were changing and only want to deploy some changes, the UI can be handy.

  • I've not had problems deploying changesets from SBs that are one release ahead of prod, except when I am deploying first from a dev sandbox to a full sandbox, when both are on Vx + 1 and prod is on Vx. Once you deploy a changeset, it seems to be "locked" to that API version; if your full SB testing goes well and you want to deploy from dev to prod, you have to clone the changeset first. May 18, 2014 at 18:28
  • Thomas: ah -- so that explains it -- I didn't realize it was the two step process: first from dev to qa sandbox that caused the lockout from dev to prod because I seem to have occasionally been able to deploy from dev to prod in the past when they were out of step version-wise. At least there is a workaround (cloning). Thanks for the tip
    – cropredy
    May 19, 2014 at 17:13

You must log in to answer this question.

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