IT puzzle pieces in the cloud

Enterprise Salesforce Team Recipe

This is a stream-of-consciousness consideration of SaaS vs Custom vs Budget for organizations that use Salesforce CRM products

The best practice in Salesforce when providing a feature to users is to first look at the standard components, then in App Exchange and if neither of those have what you need, build it yourself (or have a partner build it with you). This is repeated over and over again in articles, videos, and training content developed about how to get the highest ROI using Salesforce. So why is the question asked so often, and why do some many organizations follow the least beneficial path in response?

One reason that seems drive a lot of decisions is that because each business has its unique factors that it requires a unique solution.

Another common reason often cited for custom development on top of Salesforce is that their needs are “not supported out-of-the-box”. This is sometimes elaborated with “we tried to use it out-of-the-box, but it didn’t work”.

The reality is that these organization, at some level, chose a Software-as-a-Service solution as the best value to fulfill CRM and related needs. This is an architecture to go with buy-before-build where most of the needs have already been paid for. In a well-managed enterprise architecture, any custom development once the buy-before-build principle has been realized with the selection of a SaaS solution requires an exception case.

The reasons often present for the exception case of building custom within Salesforce (when a case is presented) seem perfectly valid. If the product doesn’t provide the functionality required, custom is the way to go. What requires more consideration is how this conclusion was reached.

Sometimes it is made by stakeholders with no SFDC administration experience doing a search on the-search-engine-everyone-uses and coming up empty. It is a seldom acknowledged understanding that searching is a skill and that, like driving, it is not uncommon for people be more confident in their abilities than the evidence warrants. The next level of problem with this criterion is that being skillful in searching in one area of interest will not always translate to searching other topics. One factor that may not be (though should be) common knowledge is that the results of the same search can vary greatly when run from different user accounts. The search engine “learns” the types of results the user usually responds to and will provide the results prioritized based on previous searches.

The same issues with search can carry over to stake holders who do perform administrative tasks in Salesforce on a regular basis. Further, the predictive prioritization provided by the search engine will include what the majority have followed, whether it is the most correct or most accurate response to the query.

A scenario that is as likely as the subject matter neophyte searching for answers is when the search is performed by someone who is skilled in custom development. Here the same factors come to play both in how the questions are asked, i.e., “how to develop [solution x]”, how the search results will be ordered (based on most frequent selection of past results focused on custom solutions) and the fact that many developers build custom solutions because they prefer not to use administrative functions.

Salesforce has been refining their capabilities since 1999 and have been very successful at it. That success is not because they missed their customer needs most of the time. There are many organizations that are paying a huge premium in maintaining their custom solutions because insufficient due diligence was performed before customizing.

This isn’t to say that customization isn’t sometimes well warranted. There are many unique needs for solutions on the Salesforce platform, and it is why the Salesforce platform is as flexible as it is.

A well-architected and managed Salesforce org will have a mix of admins to developers that is at least even, if not heavy on the admin side. Depending on the size of the org, either the role of architect can be an external consultant, or the full-time architect will work with external development teams for the occasional custom requirement.

One misunderstood Salesforce certification is the Platform App Builder certification. It is listed in both the Administrator and Developer career path definitions, and it favors entirely meta-data-based solutions. This is how the out-of-the-box capabilities provided by Salesforce can be “customized” without having to maintain custom code. It also allows for developer to create custom components that can fill in any minor feature gaps that can be managed by administrators after development.

Many organizations are struggling with staffing competent and experienced Salesforce developers when there are many skilled administrators out there than can help an organization make better use of their original decision to buy rather than build.

© Scott S. Nelson
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.

© 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.

Scott S Nelson

© Scott S. Nelson