Why Change Sets Suck (the Time out of your DevOps Process) – Part 2
Authored by Jen Nelson | Senior Solution Consultant | Copado
Hello, #AwesomeAdmins!
In our last post, Why Change Sets Suck (the Time out of your DevOps Process) – Part 1, we looked at the limitations of native Change Sets solved by Copado including Version Control, Release Pipeline structure and cross-Stack Deployments.
As mentioned previously, there are many limitations to native Change Sets, and Copado resolves all of them!
In Part 2 of our 3-Part Series, we are going to focus on Deploying Standard Components, Standard Settings,Custom Settings with Values and Quality Control.
Native Change Sets do NOT include Standard Metadata
When searching for Metadata Components to add to a native Change Set, there are no Standard Metadata Components available for Selection.
That means, for example, any changes that you have made to Standard Fields, including modification of Standard Value Sets, as well as Standard Layouts, Standard List Views and Standard Objects cannot be included in a native Change Set.
Instead, you must manually track these Standard Metadata Component changes and manually update each Salesforce Environment accordingly.
Copado uses the Salesforce Metadata API and all Supported Metadata
Any Metadata Component supported by the Salesforce Metadata API is available for selection in the Copado Metadata Grid on Commits and Deployments.
Notice in the Copado Metadata Grid example shown below how none of the Components that I have selected have __c at the end of the Component Name…that means that everything I have selected below is a Standard Component!

Gone are the days of having to manually track and update:
- Changes to Standard (native) Page Layouts
- Changes to Standard (native) Fields
- Changes to Standard (native) ValueSets; examples of StandardValueSet would be the Type or Industry Picklist Values on the Account Object
- Changes to Standard (native) List Views
- Changes to Standard (native) Lookup Filters
- Changes to Standard (native) Search Layouts
Native Change Sets do NOT include Custom Settings Values
While a native Change Set does allow us to select a Custom Setting and the Custom Setting’s Metadata:

We are only able to retrieve the Metadata, not the actual Values that we have defined behind the Custom Settings’ “Manage” button:

Copado will Commit Custom Settings Metadata and Deploy Custom Settings Values
With Copado, we can not only select the Custom Settings Metadata in our out-of-the-box Metadata Grid:

But we can also add a Deployment Task (aka Deployment Step) of Type “Custom Setting” to our User Story, so that we retrieve the Custom Settings Values we have defined in “Manage”:

No more having to track our Custom Settings Values manually and no more having to manually update each Salesforce Environment with our Custom Settings Values!
Native Change Sets do NOT include any Standard Settings
With native Change Sets, you will need to manually track any changes you make to all Standard Settings and you will need to manually update those Standard Settings in each Environment as you move up your Release Pipeline:
As of this writing, Salesforce’s Generally Available API is v47 (Winter ‘20) with v48 (Spring ‘20) in Preview Sandboxes.
Depending on your Salesforce Edition, as well as Features enabled in your Orgs, there are potentially 90+ Standard Settings included in the Salesforce Metadata API and, if any of these 90+ Standard Settings were changed as part of your DevOps Process, you are unable to include these Standard Settings in native Change Sets and would, instead, have to manually track and update these Standard Settings on each Salesforce Environment.
Copado’s Metadata Grid supports all Metadata supported by the Salesforce Metadata API – including Standard Settings
With the Copado Metadata Grid, all Standard Settings in the Salesforce Metadata API are available for selection.

Native Change Sets do NOT include any Quality Control of Metadata Changes Deployed that is not natively required by the Platform
The only quasi-Quality Controls available in native Change Sets are the native Salesforce Platform-required Apex Tests with Code Coverage and Validation-only Deployments.
Copado includes extensive Quality Gates
The only quasi-Quality Controls available in native Change Sets are the native Salesforce Platform-required Apex Tests with Code Coverage and Validation-only Deployments.
Copado Quality Gates can be run from User Stories, but oftentimes can also be run from an Org Credential to include a complete Environment (on-demand or as a Scheduled Job), or as Quality Gates in Copado Continuous Delivery.
Native Salesforce Quality Gates
- Apex Tests with Code Coverage – bonus, Copado allows us to set Minimum Code Coverage Thresholds for each Salesforce Environment in our Release Pipelines
- Validation-only Deployments
- Native Salesforce Automations (SFA) including Approval Processes, Validation Rules, Workflows, Process Builders/Flows and Rollup Summaries, to name a few
Out-of-the-Box Quality Gates
- Static Code Analysis for Apex Best Practices via either
- the free PMD Rule Set
- an out-of-the-box integration to your own paid instance of CodeScan / SonarQube
- Pull Requests for Peer Review
- Manual “Smoke Tests” for User Acceptance Testing
Add-on Quality Gates
- Copado Selenium Testing – Automated Selenium Regression Testing on Platforms such as Sauce Labs, BrowserStack or Cross Browser Testing
- Copado Compliance Hub – a custom Rules Engine to scan key Metadata Components such as Profiles or Permission Sets for violations such as View All Data/Modify All Data being exposed to Non-System Administrator Profiles
Summary:
Native Change Sets Limitations Addressed by Copado
- Native Change Sets only cover a single-step in a Complete DevOps Process.
- Create–>Test–>Deploy–>Release–>Monitor–>Plan
- Native Change Sets have no Version Control.
- Native Change Sets do not allow for any Release Pipeline structure nor cross-Stack Deployments.
- Native Change Sets do not allow inclusion of any Standard Components, Standard Settings nor Custom Settings.
- Native Change Sets have no Quality Gates to ensure that the Metadata being Deployed is of high quality and is compliant.
- Copado covers the end-to-end DevOps Process and is 100% native to Salesforce.
Create–>Test–>Deploy–>Release–>Monitor–>Plan
Learn more about Copado’s Solutions By DevOps Stage.
Stay tuned for Part 3 of our 3-Part Series which will cover:
- Pre- and Post-Deployment Steps
- Seeding Sandboxes, Deploying Test Data and/or Deploying Data-as-Configuration-Data
- CI/CD Automation
Jen Nelson
Senior Solution Consultant at Copado
- 16 years in Salesforce ecosystem
- 11 years as an SI / ISV Partner for both the Commercial and Nonprofit spaces
- Salesforce MVP Hall of Famer
- 4 years as Downers Grove IL Admin Group Leader
- 3 years as Midwest Dreamin’ Committee Member
- 3x Dreamforce Presenter
Join Jen on Twitter and LinkedIn!

