Photo by Ruben Mishchuk from Unsplash

When Change Sets Fail in Salesforce

With the growing popularity of DX and the GA release of DevOps Center, I’ve seen fewer questions about Change Sets the last couple of years. I expect that organizations that have used change sets successfully for a long time are less motivated to change their processes and those that had issues have had sufficient time to move to the newer options.

What I have seen in the past around legacy processes that work well for small teams is that they are often passed to newer members experientially and at some point someone joins that is not mentored into to how things have been done and struggle on their own. Here are a few tips for those that run into this gap with change sets.

Practice makes it home by dinner time

Even the simplest change can result in big problems if something critical is missed. Always test the change set by pushing from one sandbox to another that has been refreshed since the last production update. If there is a possibility of changes being done directly in production, this means to create or refresh the test target sandbox immediately before the deployment test.

Go small or stay home

Incremental changes are best. I prefer to do a deployment anytime there is a completed task that has tested in development. The push could just be to a fresh sandbox with the final production release being a series of pushes. Another approach is to use dark deployments, pushing out tested work products incrementally even though not all pieces are ready for users. The dark deployments may require some custom metadata types or permissions to keep them from being used before they are ready, something it is really useful for large projects to avoid big-bang pushes.

The incremental pushes to sandboxes should result in a series for change sets. As they progress, dependencies may be discovered and indicate a need to revise the change sets so that dependencies are pushed first. Again, the dark deployments are useful here.

The might DX

Among many good reasons for switching to DX, verbose error messages for deployments helps speed up debugging. Using Workbench, it is possible to turn change sets into packages for use in DX, which is handy if you are just starting to migrate to DX. Again, test deployments against fresh sandboxes are critical to avoiding critical situations.

The only constant…

Is change, not change sets. Eventually change sets will probably go away, so if you are reading this post you are either bored and avoiding more productive tasks or you are struggling with a change set today.  Now is a good time to start looking into alternatives.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson
eBook Transition legacy systems MFA

Salesforce MFA and the Salesforce Platform User License

I’ve seen a lot of FUD around the new MFA requirements from Salesforce. Understandable, given there are many people tasked with managing this who do not have experience in managing it.

One common question is around API integrations and how to do MFA. While this can (and in some situations, should) be done, it is not required.

From Salesforce Multi-Factor Authentication FAQ:

Publish Date: Dec 13, 2021

How will Salesforce exclude MFA-exempt user types from auto-enablement and enforcement?

There are several user types, including API/integration, automated testing, and RPA accounts, that aren’t required to use MFA. We’re currently working on plans for how customers can exclude these types of users from future auto-enablement and enforcement milestones. We’ll update this FAQ and your products’ documentation when more information is available.

See also:

So, in conclusion just set it up with a Salesforce Platform User License, generate a token for that user, then use the APIs to login or login with username and Password+security token, depending on the application.

HTH
Regards,
Scott S Nelson

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

What has more impact to Salesforce ROI than downtime, defects, or time to market?

It’s probably not what you were thinking (and kudos if it is):

The number one killer of Salesforce success is user adoption. The first part of planning must include a user adoption strategy, and the first App Exchange install should be the Salesforce Adoption Dashboards.

Recommended Trailheads:

Facebooktwitterredditlinkedinmail
© Scott S. Nelson