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 mighty 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
We can't display this page because your browser blocks cross-domain cookies, but you can view this page in Salesforce Classic. Click here to open this page in Salesforce Classic.

Salesforce Lightning Admin browser blocks cross-domain cookies use Classic

I see lots of other folks running into this and thought I would post the fix along with my thoughts. (TL;DR).

The error message is “We can’t display this page because your browser blocks cross-domain cookies, but you can view this page in Salesforce Classic. Click here to open this page in Salesforce Classic.” It can happen in several screens and is a result of some of the base domain changes that Salesforce has been making coupled with the security changes browsers have been making. For chromium-based browsers (Edge, Chrome, Brave, etc.) the fix is to add your domain to the cookie exception list.

With screens, the process go as follows:

Go to Settings > Privacy and security
Go to Settings > Privacy and security
Select Cookies and other site data
Select Cookies and other site data
Under Sites that can always use cookies click the Add button
Under Sites that can always use cookies click the Add button
Paste your SFDC domain path in the Site dialog and Check Including third-party cookies on this site
Paste your SFDC domain path in the Site dialog and Check Including third-party cookies on this site

Click the Add button and

Refresh your Salesforce screen [F5]
Refresh your Salesforce screen [F5]
Tada!

Note: You could use a wildcard in place of the sub-domain for all salesforce domains, but I don’t recommend that as it would leave you vulnerable to some miscreants that use their orgs for nefarious purposes.

To summarize:

  1. Go to Settings > Privacy and security
  2. Select Cookies and other site data
  3. Under Sites that can always use cookies click the Add button
  4. Paste your sub-domain and domain path in the Site dialog
  5. Check Including third-party cookies on this site
  6. Click Add button
  7. Refresh your Salesforce screen [F5]
Facebooktwitterredditlinkedinmail
© Scott S. Nelson
Salesforce forgot password screen

Fix for Login to new Salesforce Developer org without token

TL;DR – San Francisco

Here’s the scenario: You signed up for a new free Salesforce Developer account. After filling the form properly you get the screen that they have sent a verification email and, lo and behold, it is immediately in your inbox. You click the link and get…a DNS error. Well, that is annoying, but understandable given the volume of traffic Salesforce deals with. It will propagate eventually, so you decide to come back later.

Later, you come back and the DNS now resolves to your shiny new org, but now the new user token has expired and instead of the prompt to change your password you just get the regular old login screen asking for a username that is in the email and a password that has never been created. This is a Charlie Brown and Lucy place-kicking moment.

Well, this has happened to me a few times, and in the past I just created a new account and eventually would get a notification that the previous org was being decommissioned for non-use. But today I didn’t feel like filling the form out again, so I tried something unique (for me)…when prompted for city on the password reset screen I first tried blank, since that is what it would be if it was never set. That resulted in a note that I was wrong (not the ISO-270001 recommendation, BTW). So I thought “what would have I set as a default response?” And then I thought “the city where headquarters is”. And I was right.

Cheers!

Facebooktwitterredditlinkedinmail
© Scott S. Nelson