If we built an entire web of objects and tons of flows and apex code that goes along with them. Would it make sense to split this into 2 pieces. The first one containing only the object and fields, and the second containing flows and apex codes? What is the best practice for a large deployment, rather than just uploading from sandbox, then validate, fix any error, revalidate, repeat, then deploy

2 Answers 2


I suggest packaging is the answer here.

The benefit here is that you can apply some form of control, including versioning, putting all your complex metadata into a version control system like git (there are lots of cloud-based git repository managers, like github, Bitbucket etc.).

Packages also require your test suite to successfully execute at the time of packaging, rather than at the time of installation, which means you are protected from test failures due to validation rules and the like on the production org.

Of course, this take time and effort to set up, and you need to start working in a much more structured manner within your team, but you'll find quality of deliverables will rapidly improve.

  • Is there a time to use change set vs packaging? Jun 1, 2021 at 14:34
  • For metadata that cannot be packaged but can be in a change set. Otherwise, for me, only for emergency fix based on quick changes made on a full sandbox, but even then this would be less preferred to a package update. Honestly, switch to packages and sfdx. They are the future direction in Salesforce.
    – Phil W
    Jun 1, 2021 at 16:43

You can use package to push the changes. Packages offer the ability to put your change set in a little, well packaged bundle and have it accessible for installation via the AppExchange.

You can also have a look at Salesforce DX and Salesforce CI which provides a much powerful and new alternative to change sets. Many third-party CI tools are available for you to choose from.

In short, packaging is a better option here as apart from what's mentioned above, you can also use version control with this. Also, note that there is NO Rollback available option for change sets, so that's another issue with change sets in addition to the fact that you can only test during deployment and if it fails, it's just a lot of rework.

In addition to this, if your company is ready to pay, then there are some really good Third-Party release management tools that are available in the market. This includes in-org tools like Flosum, hybrid solutions like Copado and AutoRABIT, cloud applications like Gearset and Blue Canvas and desktop tools like Metazoa and AppirioDX.

  • BTW, sfdx with force:source:push and force:source:pull is exactly what you would use while developing a package. The benefit of using packages, even unlocked ones, is that traceability back to the package is visible on the org on which the package is installed.
    – Phil W
    May 28, 2021 at 14:00
  • Yes, & though this will require some preparation time, but in the long run it's worth it. Also, package is also much more useful compared to change sets when there are multiple developers or teams involved. I also prefer packaging and deploying using packages because of all the awesome tools available for this process and that's a nice alternative to have. May 29, 2021 at 15:42

You must log in to answer this question.

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