SFDC Login Use Custom Domain

Trailhead Log In to Personal or Scratch Org SOLVED!

Scott S NelsonLeave a comment

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.

If you found this interesting, please share.

© Scott S. Nelson
Bone-in or Wild Caught Lobster Tails Photo by Ruben Mishchuk from Unsplash

When Change Sets Fail in Salesforce

Scott S NelsonLeave a comment

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.

If you found this interesting, please share.

© Scott S. Nelson

Some Best Practices for Developers

Scott S NelsonLeave a comment

This post consists of excerpts from a previous single page for Best Practices.

Apply Critical Thinking

If you are given a direction and the application of that direction does not appear to adequately solve the requirement, investigate other options. As a contractor it is expected to simply follow direction from the customer regardless of the outcome. As a consultant, it is your job to inform your leader or the client when something does not make sense and to provide a solution as part of the information. Anyone can report an issue; a consultant always includes a solution or an approach towards a solution along with the report.

Test Before QA

Always test either before checking in or creating a Pull Request (depending on your SCM process). The tests need to be as close to how the code will function in the real world as possible. Use a VM if that helps.

Trouble-Shooting

It is the nature of  many developers to check outside their own work first for the root cause of a n issue. Even when this is the case, simply stating that the issue is elsewhere does not result in resolving the issue in a timely manner. Always provide detailed proof of where the issue is occurring outside of your own work in a manner that is irrefutable by the person(s) that will need to address the issue. If there is any doubt about the cause of the issue, you will be made to provide this proof anyways, so have it as part of your explanation the first time.

Perpetual Student

All developers and managers of developers know that learning for a dev is a continuous process. Here are a few tips on amplifying the value of that process:

  • Research solutions every time. Technology is constantly evolving, and the perfect solution used last time may have been replaced by one that is even better.
  • Save your learning files. For years I used an archive disk and am now starting to use GitHub to save all of my learning projects. When research fails to bring a new solution to light and you knew you had solved it once before, the archive will help. So does blogging 🙂 . At the time you are learning you may think you will remember it forever. If you are continuing to learn, you may not.
  • To be continued…
If you found this interesting, please share.

© Scott S. Nelson

Common Sense Isn’t, Especially for Code (Part 2 of 2)

Scott S NelsonLeave a comment

Continued from Part 1

Determine and Describe Dependency Issues Precisely

When debugging an issue always thoroughly check everything that could be wrong with your own code and configurations before looking at factors your code is dependent on. Never assume the issue is with a dependency; find the dependency and describe it in detail. Not doing so leads to longer times to resolution with people focusing on why it isn’t their problem. In the rare circumstance where the dependency issue cannot be clearly identified, include a complete and concise description of what you have checked in your own work before asking others to check theirs.

Clean Your Code as You Go

It is easy to slip into the “I will clean it up later” mindset because you honestly intend to. More often than not, it does not happen because of shifting priorities. At the minimum, you should do your clean ups as you do your check-ins. You will also find it easier to work with your code if it is neatly formatted and well organized as it makes questionable designs stand out more.

Scripts Must Be Non-Destructive

Scripts should always check for perquisites and be written in such a way that if they are run repeatedly the actions will result in a fully functioning system.

When adding files or folders, check for existence and back up existing before changing. Multiple versions of backups should be kept. My general rule of thumb is 3 versions. Older versions should be removed as part of the script to prevent disk space issues.

A rollback approach should always be tested before running the script.

If you found this interesting, please share.

© Scott S. Nelson