Technology should make things easier. I make technology easier.
After many years as a WebLogic Portal consultant (and a few years delivering WebCenter solutions), I have found a new end-to-end platform that I am passionate about helping people with: Salesforce (dot com).
Follow me for tips on Trailblazers (too) for regular responses to member questions and subscribe to my YouTube channel for curate SF content.
Having problems logging in to your dev, personal, or scratch org to verify the completion of a 500 point Trailhead lesson? Personal dev orgs are Production orgs and use login.salesforce.com and dev sandboxes are sandboxes and use test.salesforce.com and since I usually just use the CLI to log in to scratch orgs I can never remember which to use. And I don’t need to. There is enough to remember about Salesforce and technology in general, so if I can simplify something to a common approach, I always do. In this case, when authoring an org of an OAuth connection I always use the Use Custom Domain option and paste in the domain of the org I want to use.
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.
A frequent question on Trailhead for new admins and developers is how to edit the fields displayed in quick actions, global actions, and Lightning components. Most of the time these fields are managed through the Compact Layout for an object.
From there you can clone the default layout and create your own. Required fields must have a value for the action to work, though these fields can be left off if they have default values or there is a before action that sets the value.
The upside to modern PCs is that so many file associations are created for us automatically. This is offset to a degree because the default setting in Windows is to hide file extensions, so that what you see is just the name and an icon. This is especially problematic for CSV files as most people who use Windows have Excel and since the friendly green icon is fronting the file the habit to just click it prevails.
Sometimes, this association is fine. Simple text data delimited with commas or tabs can be converted to Excel format with no manual intervention and everything looks fine. But, if any of the fields have commas, or are dates or numbers, than Excel makes lots of assumptions that it doesn’t tell you about and changes the data to match the assumptions. One does not need to be a data scientist to know this is bad. Indeed, one only needs a pulse to be annoyed by it, and if you don’t know why the data is being messed up, frustration is a common reaction.
The first thing I recommend is to change your Window settings to show file extensions. There are instructions provided by Microsoft for this here.
Next, develop the habit of opening CSV files using one of the more time-consuming (and reliable) methods. Method 1 is to open the CSV file in a text editor (my personal preference is EditPad, and there is a good list of others here). Then create a new Excel workbook or sheet, copy the contents of the CSV file from the text editor and use the Paste > Use Text Import Wizard option.
The simplest approach is to accept the defaults on the first two steps and on the third step select all columns by holding the Shift key, scrolling to the right and click the last column, and choose the Text column format.
This will create a clean separation by column with no auto-formatting applied. Then Finish and you will have the data as you expected.
For larger files, I suggest reading this thread on SuperUser.com.
When creating data in Excel for CSV upload, format all the columns as Text before saving as CSV. If you have to do the same data transforms regularly, I recommend creating a template with formulas.
Probably the hardest habit of all for most users to adopt is when opening the file in Excel just to view its contents is to select No when prompted to save the changes.
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:
Click the Add button and
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.
Go to Settings > Privacy and security
Select Cookies and other site data
Paste your sub-domain and domain path in the Site dialog