Tag Archives: salesforce data

An abstract representation of a hotfix.

Improve Your Salesforce Hotfix Strategy

Many devs and admins who follow governance and release best practices find making a Salesforce hotfix challenging.  If you struggle to configure and deploy hotfixes in a timely manner, you’re not alone. And when it comes to creating a hotfix environment in Salesforce, traditional data set building is slow, laborious, and prone to error—even with Data Loader.

But as Victoria Livschitz said, “It’s not the prevention of bugs but the recovery—the ability to gracefully exterminate them—that counts.” 

And that’s exactly what Prodly allows you to do. 

Prodly lets you automate your hotfix strategy and rapidly fix, test, and promote essential changes to production. In this blog post, we’ll examine what hotfixes are, how not to handle them, and four ways Prodly improves your hotfix strategy.

What Is a Salesforce Hotfix?

In Salesforce, a hotfix is a simple configuration change that addresses a key issue impacting day to day business. Oftentimes, one is required due to a bug a user reports—so you need to fix it immediately.

Although a hotfix may not involve a major change to your production environment, it’s business critical and therefore urgent. Because it addresses a bug that’s adversely affecting your business operations, it can’t be postponed until your next major release.

That’s why you need the ability to implement a patch as efficiently as possible without getting bogged down in error-prone manual processes.

Salesforce Hotfix Workflow: Inefficient and Costly

If you’re implementing a hotfix in Salesforce, the process probably looks something like this:

  1. Purchase a Partial Copy sandbox or Full Copy sandbox to use as a hotfix environment—at 20 percent or 30 percent of net spend.
  2. In this environment, determine what’s causing the issue. Then fix the issue and test it.
  3. Use change sets to promote the approved change to your production org. That involves creating an outbound change set in the hotfix environment and an inbound change set in the prod org. Then you have to validate the inbound change set and deploy the change set. 
  4. Migrate (either manually or with Data Loader) any configuration data required for the hotfix.
  5. Use change sets to promote the change to your Developer sandboxes and the Full sandbox you use for training.

Unfortunately, this strategy can be cost-prohibitive due to the expense of purchasing a sandbox to use as a dedicated hotfix environment. Moreover, the multiple manual steps required for each change set deployment make this process highly labor intensive and time consuming. 

Never Make a Patch Directly in Production!

Knowing how expensive and inefficient it is to implement a hotfix in Salesforce, you might be tempted to rush things and make the hotfix directly in production. 

A word to the wise, however:

Never, ever, make a hotfix directly in your prod org!

Why? Because if the hotfix introduces any new issues, you’ll be stuck with a much bigger headache. And that could affect your CX even more!

Create a Prod Hotfix Strategy Before the Next Bug

To be prepared to make a mission-critical change in a timely manner, don’t wait until a serious issue arises to design a hotfix workflow. Instead, get ahead of things and establish a production hotfix strategy before the next bug occurs. Your strategy should:

  • Appoint team members to configure the hotfix
  • Designate an environment where you’ll make the change and test the fix
  • Specify how you’ll promote the fix into production
  • Determine which other orgs will need the fix and how you’ll back promote the fix
  • Include a post mortem to analyze the event and prevent future issues

4 Ways Prodly Can Improve Your Hotfix Strategy

Now you have a basic game plan for dealing with hotfixes, let’s take a look at how Prodly can improve your strategy.

1. Use a Free Environment for Dedicated Production Support

With Prodly Sandbox Management, you don’t need to purchase a new Partial Copy or Full Copy sandbox as a dedicated hotfix environment. You can simply use a free Developer sandbox or Scratch org, because Prodly lets you easily and quickly move data into it. This saves your Partial Copy and Full Copy sandboxes for higher value projects in Salesforce.

2. Seed the Impacted Configuration to Your Hotfix Environment 

Your hotfix environment needs to be a reproduction of your production org. However, you don’t have time to recreate all the data from the prod org in the sandbox. 

In Prodly, you can compare your orgs to see any metadata differences between your prod org and your hotfix environment. If there are differences that will impact the patch, you can easily review and sync them to your hotfix environment. 

You can use sandbox seeding to automatically migrate the affected data to the hotfix environment. The sandbox seeding wizard allows you to quickly select data and upsert it to your hotfix environment.

Simply select a root object in your prod org, along with any related objects. Next, temporarily deactivate all events for the duration of the deployment to avoid complications. Finally, implement the deployment.

Note that Prodly provides prebuilt templates for common data seeding needs that can save you even more time.

3. Promote the Hotfix Back to Production

With your hotfix environment set up, you can determine what the problem is, configure the required change, and test the change without any risk to your prod org. Once you’re satisfied the change works, Prodly makes it easy to seamlessly move the change back into your production org—regardless of whether the fix involves metadata or data.

You also don’t have to use change sets and Data Loader to manually push the change to your prod org. You can leverage Prodly to automatically migrate the metadata and data while still maintaining complex object relationships. Simply select the configurations you want to deploy, and then deploy all the metadata and data changes at once.

4. Sync the Salesforce Hotfix to the Rest of the Orgs in Your Stack

While you’ve been rushing to fix the bug, your teammates may have been working on the next release. It’s essential to sync the rest of the orgs in the release path with your production org and training environment so they don’t reintroduce the bug or cause new ones. 

Prodly allows you to sync data to up to five orgs simultaneously. So once you’ve promoted the patch back to production, you can quickly and easily sync the metadata and data changes from production to the other orgs in the stack. The benefit is that by doing this, you’ll bring your other sandboxes up to date without having to wait to refresh them

An abstract representation of a hotfix.

Salesforce Hotfixes Are Easy With Prodly

Let’s face it: Bugs happen. 

And when they impact your day-to-day business operations, you need to fix them—fast. With a robust hotfix strategy and Prodly, you can quickly, efficiently, and easily create a hotfix environment, fix the issue, and promote the change to your production environment and other orgs. And you can do all this without the high costs of purchasing an additional Partial Copy or Full Copy sandbox in Salesforce.

 

To learn more about Prodly DevOps, contact us today.

An abstract image showing a concept of Salesforce DevOps

Salesforce DevOps: What Took So Long?

Salesforce DevOps has been a long time coming. However, DevOps has long been a popular methodology for IT teams. So what has caused the slow adoption of DevOps by the Salesforce community?

First, Salesforce isn’t a code-first environment. Second, the production org has always been the source of truth. And third, creating reproducible environments has been extremely challenging. 

In this blog, we take a closer look at these factors. Then we explain how Prodly directly addresses each one to facilitate Salesforce DevOps. 

An abstract image showing a concept of Salesforce DevOps

3 Reasons Salesforce Was Slow to Adopt DevOps

We can attribute the Salesforce ecosystem’s slow adoption of DevOps to the following key principles.

1. Salesforce Is Not a Code-First Environment

Salesforce is first and foremost a low-code platform. It’s as much declaratively configured as it’s programmatically configured. That’s why it’s such a great tool for low-code developers such as Salesforce admins and citizen developers.

Often, Salesforce admins, business analysts, and project managers have great ideas. Unfortunately, they’re still excluded from conversations due to their inability to work with code-heavy DevOps tools.

To achieve successful adoption of DevOps for any team, low-code and no-code citizen developers must be first-class citizens from the very beginning. This is why Prodly DevOps is designed with the lowest technical user in mind. 

2. The Production Org Has Historically Been the Source of Truth

Within Salesforce, we think of production as the source of truth. The problem is that production is always evolving—and there’s no real history of changes. 

In DevOps, the code is the source of truth. The code is versioned, and every change is stored in a repository so it’s easy to roll back changes if there’s an error. Think of the “track changes” feature in a document.

For Salesforce DevOps to be successful, we need to version not just the code, but also the declarative configurations. 

This is why Prodly helps you version your Salesforce data with GitHub, Azure, and Bitbucket integrations.

3. Creating Reproducible Environments Has Been Challenging 

One important DevOps principle is to be able to easily create reproducible environments. 

Why? Because by giving each developer their own org, they have a safe place to play around and test new ideas without stepping on each other’s toes. So it’s imperative to be able to quickly spin up and discard new orgs.

Salesforce has sandboxes. However, they’re not truly reproductions of production because they don’t contain all your data. 

Even Full Copies get out of sync with production quickly—plus, they can only be refreshed every 30 days. 

Salesforce data is highly relational, and those data relationships are hard to maintain org to org. That’s why most companies fall into one of two buckets:

  • Everyone shares the Full or Partial Copy sandbox. All the work happens here, and people overwrite each other’s work by mistake. This frequently results in access restriction to certain data. 
  • They work in Developer Pro sandboxes without the right test data, meaning they can’t efficiently build new stuff or test it very well.

To be successful with Salesforce DevOps, you need to be able to create true copies of production. What’s more: You need to be able to do this really quickly.

That’s why Prodly Sandbox Management allows you to select, filter, and seed data into any org in minutes. Check out Maximize Your Salesforce Orgs With Sandbox Management to learn more.

Schedule a demo to discover how to enable Salesforce DevOps with Prodly.