What are the most effective and efficient ways to manage objects, fields and workflows? Our setup involves one developer sandbox to try out ideas, a QA sandbox to validate changes, and the our production org. I'm currently using the Force.com Migration Tool and associated XML files, but they can easily get out of date and not everything is metadata driven.

What other options exist and are recommended?

6 Answers 6


Here are some of the pros and cons that I can think of off the top of my head. YMMV.

Change Sets


  1. Ability to keep a running set of changes that were made (unlike the Force.com IDE)


  1. Very manual, and therefore, error prone.
  2. Slow UI. Can't sort on last modified date, for example.
  3. Can't tell what was actually changed (have to manually keep track elsewhere or use the Audit log)
  4. Removing from the change set must be done on a single item by item basis.
  5. Doesn't support as many components as the Force.com IDE or migration tool.

Conclusion: Best fit for very small sets of changes done by a single developer on an infrequent basis.

The Force.com IDE process


  1. Easy to see what has changed.
  2. Can zip the source and destination prior to deployment.
  3. Can synch up with a central repo (e.g., SVN), in theory.


  1. No ability to recall a previous configuration. This is a showstopper for large deployments. If you are working on a large project and it can take you 10+ minutes to build up your deployment (that isn't the problem, though). The issue is when that deployment fails your validation step, you have to exit out of the deployment UI to fix it, which loses it.

Conclusion: Best fit for small sets of changes, possibly by a team of developers.

Ant migration tool


  1. Scritable. This allows you to incorporate it within other processes. You can combine it with data loading scripts, continuous integration, etc. If there are data issues and/or certain components that don't deploy well (e.g., SF bug) you can set up scripts to parse/transform into an acceptable state.
  2. Depending on how you have package.xml file(s) set up you might be able to make it less of a chore to update your scripts.


  1. May have to manually update XML files.

Conclusion: A decent amount of upfront work, but good for long running projects/maintenance.

Other As for your concern about not having support for everything in metadata, change sets actually support less components.

  • Thanks, @peter! The pro and con list is definitely helpful.
    – Mike Chale
    Commented Aug 3, 2012 at 19:32
  • 1
    Re: Eclipse IDE - I've added Maven tasks in my IDE. You can use local task repositories even if you don't have JIRA and the option to change contexts easily when you work on several features in same time or just ctrl+click files in the context, right click, force.com -> deploy to server can be a real timesaver.
    – eyescream
    Commented Dec 15, 2012 at 9:20

Do you know about Change Sets? They allow you to move code, objects, fields, triggers, page layouts, profiles, etc.... from one sandbox to another or to production. There is a full validation process as well.

They will change your life.


  • Change sets are great! A couple of caveats: change sets work as long as the orgs are related. You can't send a change set from a Developer Edition org to a sandbox. Also, change sets can't do destructive changes. If you want to delete a metadata component you need to use the migration tool or the IDE. Commented Aug 3, 2012 at 17:20
  • Yes, I've used Change Sets for some things that I couldn't quite get with the Migration Tool. Other than creating packages, I'm hoping to find something more substantial/less manual.
    – Mike Chale
    Commented Aug 3, 2012 at 17:24
  • Change Sets don't show the full picture unfortunately. There is often many rows of configuration data, especially for custom Apps that can't be included in Change Sets, so you have to then import and export the data, which is a pain.
    – JodieM
    Commented Aug 6, 2012 at 3:59

Another option to consider is Workbench (workbench.developerforce.com). This will allow you to build packages from your sandbox organization and upload to your QA/production org. The Workbench tool has a lot more functionality too. It is a combination of Apex Explorer, Apex Data Loader and Migration Tool.

  • Hmm, I haven't tried that and will look into it. Thanks!
    – Mike Chale
    Commented Aug 4, 2012 at 12:01
  • What you want to do is go to the org from which you wish to migrate metadata and then simply browse to (or open a new tab) to workbench.developerforce.com and it will log you in to the workbench.
    – kadmin
    Commented Aug 4, 2012 at 17:36
  • Here is the FAQ about Workbench's metadata retrieve/deploy functionality: wiki.developerforce.com/page/Workbench#Metadata Commented Aug 15, 2012 at 18:05

I use two different items for my deploys.

I use the IDE with Eclipse for big deploys - especially when it involves Code.

I use ChangeSets for small deploys - or deploys that involve things like Workflow Rules.

Change Set are nice, but they can get bulky and time consuming with huge deploy setups. Plus not everything is included in Change Sets for Deploys.

The IDE is great, but you can't really deploy workflow rules (I haven't been successful at least). Plus it can be a bit slow especially if you lots of tests in the system.

My preference is to always go Dev sandbox -> Full copy QA Sandbox. Validate changes in QA Sandbox. Any changes happen in Dev and then redeployed. Then Dev Sandbox -> Production.

I don't use either the IDE or Change Sets to track actual changes. I use Cases in our production system to track what was getting change. The plus side is if the item has a description I can include a link to the case for future reference.

  • Upvoting for the idea of using Cases to help track changes. I'm surprised you say the IDE can't deploy workflow rules, though; those have metadata and the Migration Tool handles them with ease.
    – Mike Chale
    Commented Aug 9, 2012 at 11:38

There is a paid tool on the appexchange

I have never used it, and have no idea about it's suitability. But if you are looking for alternatives it could be something to consider.

  • I've used this tool and it works. Is kinda slow and only works on Windows. Just some caveats that might sway your decision. Commented Aug 8, 2012 at 20:22
  • Snapshot works with OSX also. Not so well all the time, but it can work. Try different browsers. Commented Sep 9, 2012 at 4:40

We use Change Sets. I'll add a PRO to Peter's list

  • Ability to verify/validate changes in production prior to release.

We use this for every release (Dev and Config) and have had no issues with it.

  • One can also verify/validate changes in production prior to pushing via the IDE. There's a Validate button. Not disagreeing with you; just pointing out that the functionality is not unique. Commented Sep 9, 2012 at 4:39

You must log in to answer this question.

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