2

What is the achilles heel of changesets for you? What bugs you the most about change sets?

closed as off-topic by Matt Lacey Feb 7 '15 at 6:16

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Question that are intended to propose ideas, solicit opinion or provoke discussion are better asked in an alternative forum." – Matt Lacey
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Hey Kevin, I like the idea of this question but it's not a good for SFSE so I have to close it. This is a place for questions with a precise answer, not for questions that would benefit from discussion. I'd love to see this on the success community though! – Matt Lacey Feb 7 '15 at 6:16
1

Outside of personal preference (I find them to be cumbersome), I have two reasons I stay away from them.

First, when deploying custom fields, by default nobody has access, requiring that you take a second step to manually configure the access, resulting a greater opportunity to miss a step.

But the biggest issue I have encountered, is more related to the interface and the mindset of the people that put them together. I have seen too many pieces being forgotten, resulting in multiple changesets.

I am sure people with argue that you can get the same situation with IDE Deployment packages, but in my experience, the steps to building a changeset seem to encourage incompleteness.

  • 2
    Agree that the Change Set UI is cumbersome. You CAN add profiles to the Change Set (its in section below components) which will allow the FLS to be brought over with the Change Set. Then you don't have to do manual step. In general I suggest for "Click Admins" for simple deployments use changesets. For complex / repeatable deployments use Force.com Migration Toolkit (ANT). For one off complex deploys use Force.com IDE Deploy function. – CoryCowgill Feb 6 '15 at 19:31
  • @CoryCowgill If you include the profiles, are you deploying ALL permissions (System, page layouts, standard object, etc...) or is it similar to the IDE where it only includes the permissions related to the objects you include? – Tezyn Feb 6 '15 at 19:45
  • It's the same as the metadata API. Only elements included in the change set will have their permissions modified on the included profiles. Keep in mind, though, that general user permissions are always copied, such as modify all data or API only user. – sfdcfox Feb 6 '15 at 20:00
0

I wish change sets were more like version control:

They would be much more useful if they merged changes from different source orgs into one target org, rather than simply overwriting changes of the first change set. It'd be even greater if they supported functionalities like branching/reversing commits.

  • Branches would be awesome. However, change sets are largely merges, Not overwrites. Perhaps you might want to be more specific? – sfdcfox Feb 6 '15 at 20:04
-1

I wish I did not have to specify changes down to the field level. I'd prefer to select an object and have every change on that object get transferred without having to list each one specifically.

  • You can do this. It's called "add dependencies". While I can think of reasons why one would not like change sets, thus isn't really applicable. – sfdcfox Feb 6 '15 at 20:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.