Sort by Topics, Resources
Clear
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Salto for

Salesforce

Articles

SHARE

10 Hidden Pitfalls of Salesforce Change Sets: What You Need to Know

Sagi Bracha

June 13, 2024

4

min read

Salesforce change sets, while widely used for deploying metadata between Salesforce orgs, have several notable gaps and limitations. Here, we’ll delve into these issues, highlighting the challenges that many Salesforce admins and developers face.

Deploying with Salesforce change sets can often lead to a slow and cumbersome experience. The process requires careful preparation and patience due to its inherent complexities and manual steps. As you prepare to dive into the specific gaps and limitations, it's important to be aware that these challenges can significantly impact your workflow and deployment timelines, making it essential to be well-prepared for the process.

Experience the Ease & Confidence of NetSuite Customizations with Salto

Automate the way you migrate Jira configurations from sandbox to production

STAY UP TO DATE

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

1. Manual Tracking of Changes

One significant drawback is that change sets don't automatically track changes in your org. This means you must manually remember and record every change made in your sandbox before using change sets to deploy them. 

2. Cumbersome Metadata Selection Process

When creating a deployment using change sets, you can select one metadata type at a time. For instance, you'll need to choose the fields, click save, then choose templates and save again. If you're deploying five different metadata types, this becomes a repetitive and tedious process involving many clicks.

3. No Rollback Mechanism

Perhaps one of the most significant limitations is the absence of a rollback mechanism. If something goes wrong during deployment, there is no straightforward way to revert to the previous state, increasing the risk associated with deployments.

4. You Can’t Save Your Metadata Scope

Unfortunately, your metadata selections aren’t saved. If you need to move the same package to a higher org, you'll have to repeat the entire selection process again. This lack of persistence adds unnecessary redundancy and frustration to the deployment process.

5. No Target Org Visibility

Change sets don't provide any visibility into your target org, so if you need more context, you’ll have to explore it yourself. This lack of visibility can lead to uncertainties and potential errors during deployment.

6. Limited Dependency Management

While change sets allow you to add direct first-level dependencies, they don’t support the dynamic addition of further dependencies. This limitation can result in incomplete deployments or additional manual steps to ensure all necessary components are included.

7. Incomplete Deployment Scope

Not all metadata can be deployed using change sets. For example, standard picklist values and sales processes can't be moved. This restriction necessitates manual updates in the target org, leading to potential inconsistencies. A common example, is that change sets don't support the deployment of specific sections of a Profile. This all-or-nothing approach can complicate deployments, especially in complex environments with extensive profile customizations.

8. No Conflicts Alerts

Change sets won’t alert you of conflicting changes. This means that if you’re trying to update an element in production that was already changed by someone else on your team without you knowing, you’ll just overwrite their work.

9. No Version Control Integration

Change sets lack integration with version control systems, making it challenging to maintain a robust version control strategy. This can lead to potential issues with tracking changes and managing different versions of metadata.

10. No Partial Deployments

If you hit an error, you’ll need to fix it and deploy everything again from scratch. 

STAY UP TO DATE

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

The good news is we have a free option to supercharge change sets -  Change Set Helper Chrome Extension. This handy little extension lets you sort components by last modified date or user without leaving Salesforce, which is a lifesaver when you're trying to keep track of what needs to be deployed. Plus, you can search and order components by any field.

Need something more robust? If you’ve come to a stage where Change sets are just too much of a drawback, Salto might be the solution for you. Check out this article highlighting the benefits of using Salto.

WRITTEN BY OUR EXPERT

Sagi Bracha

Marketing

Sagi is a Product Marketing Manager at Salto, overseeing Salto’s Jira, Salesforce and PLG business motions. Driven by data and audience insights, Sagi is excited about designing custom made, customer centric go-to-market strategies. Sagi also plays the keyboard in Salto’s band, and enjoys dancing and reading in her free time.

Sort by Topics, Resources
Clear
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Salto for

Salesforce

Salesforce

SHARE

10 Hidden Pitfalls of Salesforce Change Sets: What You Need to Know

Sagi Bracha

June 13, 2024

4

min read

Salesforce change sets, while widely used for deploying metadata between Salesforce orgs, have several notable gaps and limitations. Here, we’ll delve into these issues, highlighting the challenges that many Salesforce admins and developers face.

Deploying with Salesforce change sets can often lead to a slow and cumbersome experience. The process requires careful preparation and patience due to its inherent complexities and manual steps. As you prepare to dive into the specific gaps and limitations, it's important to be aware that these challenges can significantly impact your workflow and deployment timelines, making it essential to be well-prepared for the process.

What if Zendesk was 4x less work?

Request a Demo Get started with Salto

1. Manual Tracking of Changes

One significant drawback is that change sets don't automatically track changes in your org. This means you must manually remember and record every change made in your sandbox before using change sets to deploy them. 

2. Cumbersome Metadata Selection Process

When creating a deployment using change sets, you can select one metadata type at a time. For instance, you'll need to choose the fields, click save, then choose templates and save again. If you're deploying five different metadata types, this becomes a repetitive and tedious process involving many clicks.

3. No Rollback Mechanism

Perhaps one of the most significant limitations is the absence of a rollback mechanism. If something goes wrong during deployment, there is no straightforward way to revert to the previous state, increasing the risk associated with deployments.

4. You Can’t Save Your Metadata Scope

Unfortunately, your metadata selections aren’t saved. If you need to move the same package to a higher org, you'll have to repeat the entire selection process again. This lack of persistence adds unnecessary redundancy and frustration to the deployment process.

5. No Target Org Visibility

Change sets don't provide any visibility into your target org, so if you need more context, you’ll have to explore it yourself. This lack of visibility can lead to uncertainties and potential errors during deployment.

6. Limited Dependency Management

While change sets allow you to add direct first-level dependencies, they don’t support the dynamic addition of further dependencies. This limitation can result in incomplete deployments or additional manual steps to ensure all necessary components are included.

7. Incomplete Deployment Scope

Not all metadata can be deployed using change sets. For example, standard picklist values and sales processes can't be moved. This restriction necessitates manual updates in the target org, leading to potential inconsistencies. A common example, is that change sets don't support the deployment of specific sections of a Profile. This all-or-nothing approach can complicate deployments, especially in complex environments with extensive profile customizations.

8. No Conflicts Alerts

Change sets won’t alert you of conflicting changes. This means that if you’re trying to update an element in production that was already changed by someone else on your team without you knowing, you’ll just overwrite their work.

9. No Version Control Integration

Change sets lack integration with version control systems, making it challenging to maintain a robust version control strategy. This can lead to potential issues with tracking changes and managing different versions of metadata.

10. No Partial Deployments

If you hit an error, you’ll need to fix it and deploy everything again from scratch. 

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

The good news is we have a free option to supercharge change sets -  Change Set Helper Chrome Extension. This handy little extension lets you sort components by last modified date or user without leaving Salesforce, which is a lifesaver when you're trying to keep track of what needs to be deployed. Plus, you can search and order components by any field.

Need something more robust? If you’ve come to a stage where Change sets are just too much of a drawback, Salto might be the solution for you. Check out this article highlighting the benefits of using Salto.

WRITTEN BY OUR EXPERT

Sagi Bracha

Marketing

Sagi is a Product Marketing Manager at Salto, overseeing Salto’s Jira, Salesforce and PLG business motions. Driven by data and audience insights, Sagi is excited about designing custom made, customer centric go-to-market strategies. Sagi also plays the keyboard in Salto’s band, and enjoys dancing and reading in her free time.