Tag Archives: sandbox

White rays of light on a dark blue background.

Improve Your Salesforce Hotfix Strategy With Prodly

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 AppOps allows you to do. 

Prodly AppOps 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 AppOps 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, a hotfix 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 hotfix 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 the hotfix 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 AppOps 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 AppOps, 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 AppOps 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 AppOps, 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 AppOps 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, AppOps 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 AppOps 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 AppOps 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

White rays of light on a dark blue background.

Salesforce Hotfixes Are Easy With Prodly AppOps

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 AppOps, 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 AppOps, contact us today.

Salesforce Devops

Why is Salesforce so Late to the DevOps Game?

More IT teams are turning to DevOps as a solution to help them to solve incessant silos in their workflows. However, the question of why Salesforce has been so slow to adopt still remains on the minds of developers. The DevOps movement began to grow in 2007, spawned by development teams desperate for tools that solved their biggest pains. DevOps served to break down the brick wall between engineering teams and their operations counterparts so companies could keep up with demand for more frequent software releases. 

The Salesforce ecosystem’s slow adoption of DevOps can be attributed to the following key principles:

1. Salesforce is not a code first environment

Salesforce is a low-code platform that is declaratively configured as much as it’s programmatically configured. The declarative environment provided by Salesforce goes beyond the developer empowering a people with no coding experience to be citizen developers in control of their business processes. Often, Salesforce Administrators, Business Analysts and Project Managers have great ideas, but are excluded from conversations, due to their inability to work with code-heavy DevOps tools.

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

2. The production org has historically been the source of truth

In DevOps the code is the source of truth, not the software. The code is versioned and every change is stored in a repository, like track changes to a document, so it’s easy to roll back changes if there’s an error. Within Salesforce we think of production as the source of truth. The problem is production is always moving and changing, and there’s no real history of changes. 

For Salesforce DevOps to be successful we need to be able to version not just the code in Salesforce but the declarative configurations too. This is why AppOps helps you version your Salesforce data.

3. Creating reproducible environments has been challenging 

This principle is all about having a safe place to play around and test new ideas. You need to be able to create them quickly and toss them. Salesforce has sandboxes, but not truly reproductions of production because they don’t have all of your data. Even Full Copies get out of sync with production quickly and can only be refreshed every 30 days. Since Salesforce data is highly relational and those relationships are hard to maintain org to org, most companies fall into one of two buckets:

  • Everyone shares the Full or Partial Copy sandbox. All the work happens here and people stepping on each other’s toes, which results in restricting access to the 
  • They work in DevPro without data, meaning they can’t efficiently build new stuff or test it very well 

To be successful, you need to be able to create true copies of production and really fast. That’s why AppOps Sandbox seeding allows you to select, filter and seed data into any org in minutes. 

Schedule a demo to discover how AppOps can improve how your team manages data  Salesforce.

10 Benefits of Implementing AppOpps for IT Teams

Often, when it comes to implementing changes in Salesforce, it isn’t until you have to make one that you discover breakdowns and bottlenecks that keeps your team from performing optimally. Prodly AppOps is all about enabling you through an easy-to-use UI that is built to empower admins and keep your team supported by sound governance, effective change management, and give you the data that helps you use your resources wisely.

Here are just a few of the benefits of employing AppOps to create a proactive team:

#1: Improved change management

From applying a governance framework to set strategic objectives for your instance to optimizing the change request and delivery process, AppOps supports you in improving your workflows based on reliable data. Starting with your strategic approach to change management, AppOps seeks to simplify the process of change with a bias towards declarative changes that keeps admins in the driver’s seat of handling appropriate requests. 

#2: Time savings

Frequent silos and exhausted project timelines cost your team more than just money and productivity. AppOps closes the gap in your governance strategy by automating the deployment process for your Salesforce administrators. This can save hours or even days of time wasted during the release cycle. Do your team the favor of harnessing an agile approach to Salesforce changes with AppOps. 

#3: Improved quality assurance

Are you set up to handle quality assurance properly? How about handling automatic regression testing and rollbacks seamlessly? When you’re working with change requests from your users, you need a tool that’s going to support your team in ensuring that every request is fulfilled properly, from intake to completion. 

#4: Reliable auditability

Auditability is perhaps the most important part of working with customer requests and maintaining the health of your Salesforce org. Without it, it would be difficult to track whether a process is working effectively, whether resources are being used to the best of their ability or if there needs to be a complete system overhaul. AppOps Release gives you the ability to track every change so you can go back and see exactly who changed what and when. AppOps places the auditing process at the crux of how you control and manage your change workflows.

#5: Sandbox optimization

Is your company using your Salesforce sandboxes to its full capacity? Most companies aren’t. With AppOps you can refresh painlessly and seamlessly keep your sandboxes in sync with production. You can also reduce the frequency and impact of bugs and errors in your production orgs. AppOps gives you the power to use your sandboxes effectively as well as create a reliable connection between your data and your team.

#6: Reduced data errors 

The frustration of duplicate data and missing object relationships when manually deploying Salesforce records between orgs is immeasurable against the satisfaction of working with AppOps. AppOps is unique in being able to provide this level of reliability, efficiency and flexibility. This is a tool that’s designed with all of the possibilities, for your team in mind, with the reliability and data-based efficiency known for results. 

#7: Increased throughput of changes

As your team’s usage of Salesforce grows, so should your tools for managing those changes. The low-code shift has given business analysts, project managers, and business operations managers the power to drive changes and improve processes right alongside Salesforce administrators and developers. The clicks-not-code approach of AppOps means increasing the velocity and pace of releases. With AppOps, anyone on the team can be a part of the change management process while still following best practices for governance. 

#8: Happier users 

The point of strategic governance is to bring a more quality product to your end user. Implementing AppOps means that your end user gets changes faster. Your Salesforce admins will have much less busy work and move through their project timelines more efficiently. Your developers will also appreciate being more challenged with projects that fall within their skill set. AppOps is all about ensuring deployments that occur correctly every time, while allowing your team to optimize building, testing, and delivering the next release.

#9: Problems are handled more proactively

Instead of being a reactive team, AppOps empowers you to move toward proactive methodologies that help you eliminate wasteful processes and optimize those that work well. Doing the work in the beginning helps to reduce the chances of silos and bottlenecks that could have been avoided with proper planning, and by automating repetitive tasks in the release process. 

#10: Eliminate ineffective silos

Without software to support, track, and monitor the status and progress of customer requests and other projects your team handles, it is common for there to be serious breakdowns in communication. This leads to silos and backups that leaves your team loaded with unfinished projects and saddles efficiency. AppOps gives everyone the ability to safely make Salesforce improvements within the defined change processes. Treat your team to the next level of change management, the low-code option that empowers admins and strengthens IT team’s strategic leadership.

Managing low-code platforms with low-code tools is the trend for IT teams looking to increase efficiency and deliver quality changes to end users faster. The foundation of your Salesforce change management strategy should be backed by a tool that addresses each project independently to assess the path through production. Interested in taking Prodly AppOps for a test drive? Schedule a demo today. 

The basics of Salesforce sandbox seeding

Sandbox seeding, or data seeding, is the practice of populating a Salesforce org with record data after it is created or refreshed. While colloquially referred to as sandbox seeding, it’s important to note data seeding also applies to other types or Salesforce orgs as data can be populated or moved into Developer orgs, scratch orgs and even production.

Common use cases for sandbox seeding

A sandbox is merely a Salesforce environment that you can use for making changes to Salesforce, testing those changes, and training users on changes before making the changes available in production. So sandbox seeding is valuable at various stages of Salesforce development and enables admins/devs to complete projects faster, identify issues early (when they’re easier and cheaper to fix), and reduce the amount of time spent resolving bugs at every stage of development.

For example when starting a new Salesforce project, an admin will ideally start work in their own environment, perhaps a Developer or Developer Pro org. Individual Developer sandboxes provide quicker outcomes while virtually eliminating the chance of accidentally deploying unfinished work into Production or overwriting another teammate’s work. This also lessens the risk of exposing confidential data or impacting the daily tasks of your end users. Most Salesforce enhancements impact record data in one way or another, so it’s helpful to have real business data in your environment. While it is true you can use “dummy data”, substantial, real data is always best. Errors and issues are easier to spot when you’re working with real data, and you can compare against production to see exactly how changes would impact production data and user workflows.

Once the admin is confident their new solution is working the way they want, the next step is to make sure it plays nice with the changes other teammate’s have been making and, of course, production. For this you’ll want to have each individual promote their changes to a shared sandbox for testing. Frequently, admins/devs will want to seed data into the testing environment to achieve a production-like environment with current, clean data for testing so they be confident their changes will work in production.

While the majority of Salesforce changes should follow a release path where work starts in an individual Dev org and gets promoted up to testing sandboxes and ultimately pushed into production, there is also a solid argument to have an exception process for quick changes or hotfixes. Due to the urgent nature of hotfixes, companies often make changes in a dedicated sandbox and push them into production. This enables admins to keep production running smoothly, but can cause the orgs in the standard release path to become out of sync with production. After hotfixes, it is important to seed the testing and training sandboxes to ensure regular development projects have the latest configurations and data.

Finally one of the other benefits of seeding sandboxes with actual production data is that you will now be able to create a training environment for new end users and even new hires. How can you expect a new user to learn and understand how to use Salesforce if they don’t have real life scenarios and data for practice? Dummy data can inhibit the learning process because it doesn’t provide necessary business context for users. Keeping your training org current makes the transition to production easier for users.

Challenges to seeding sandboxes

Seeding sandbox testing should be a best practice for any Development/QA team, however manually having to seed data is very time-consuming and can lead to unnecessary added expenses and project delays. Data security concerns can also hinder data seeding effort, as selecting the correct subset of data and scrambling sensitive data all while maintaining the child-parent relationships that exist in production adds additional steps and complexity.

Prodly AppOps Release automates sandbox seeding to move entire relational data schemas at once with granular control over which records will be seeded and obfuscation options for protecting sensitive data. If you’re interested in reducing your admin’s workload and speeding up your Development/QA sprint cycles by automating sandbox seeding, give us a call.