Tag Archives: sandbox

An abstract representation of a hotfix.
Best Practices

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

Salesforce DevOps: What Took So Long?

Leave a comment

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.

A multicultural Salesforce team looking at a screen with Prodly DevOps.
Salesforce DevOps

10 Benefits of Prodly DevOps for IT Teams

In this blog, we’ll discuss 10 benefits of Prodly DevOps for Salesforce IT teams, including enhanced change management, time savings, improved quality assurance, reliable auditability, and sandbox optimization. In addition, Prodly DevOps enables you to minimize data errors, achieve increased throughput of changes, eliminate ineffective silos, handle issues more proactively—and make your team much happier!

#1: Enhanced Change Management

Prodly supports you in improving your workflows based on reliable data. It lets you apply a governance framework to set strategic objectives for your Salesforce instance—as well as optimize the change request and delivery process.

Prodly simplifies the change management process with a preference for declarative changes so admins stay in the driver’s seat to handle change requests.

A multicultural Salesforce team looking at a screen with Prodly DevOps.

#2: Time Savings

Prodly DevOps automates the deployment process for Salesforce admins, closing the gap in your governance strategy. This saves hours—sometimes even days—of time during the release cycle, resulting in your team meeting more deadlines and being more productive. Do your team the favor of harnessing an agile approach to Salesforce changes with Prodly.

#3: Improved Quality Assurance

Prodly helps ensure every change request is fulfilled properly, from intake to completion. This allows you to handle QA, automatic regression testing, and rollbacks seamlessly.

#4: Reliable Auditability

When you’re making changes to Salesforce CPQ or some other CPQ app, you need to remain in compliance with financial regulations such as SOX regulations.

Prodly DevOps places the auditing process at the crux of how you control and manage your change workflows. It automatically tracks every change so you can go back and see exactly who changed what and when.

Auditability is also perhaps the most important part of maintaining the health of your Salesforce org. Prodly’s change log lets you perform root cause analysis, without which it’s difficult to pinpoint the cause of bugs and other issues and determine a solution.

#5: Sandbox Optimization

With Prodly Sandbox Management, you can seamlessly refresh your sandboxes and keep them in sync with production. This enables you to reduce the frequency and impact of bugs and errors in your production orgs. 

As a result, you can use your sandboxes more effectively—plus, you can create a reliable connection between your data and your team.

#6: Minimize Data Errors

As the market-leading automation tool for Salesforce data deployment, Prodly minimizes the number of errors during the deployment process. It’s unique in its ability to deliver reliability, efficiency, and flexibility. 

You’ll never have to experience the frustration of duplicate data and missing object relationships when manually deploying Salesforce records between orgs again.

#7: Increased Throughput of Changes

Thanks to the “clicks, not code” approach Prodly DevOps uses, you can greatly increase the velocity and pace of releases. With this low-code/no-code method, anybody on your team—business analysts, project managers, and business operations managers—can be a part of the change management process while still following best practices for governance.

#8: Eliminate Ineffective Silos

Prodly gives everyone—both programmatic and declarative developers—the ability to safely make Salesforce improvements within the defined change processes. It offers applications to support, track, and monitor the status of customer requests and other projects your team handles. 

This helps prevent serious breakdowns in communication that lead to silos and backups, not to mention leave your team loaded with unfinished projects. Treat your team to the next level of change management: Prodly DevOps! 

#9: Problems Are Handled More Proactively

Prodly empowers you to leverage proactive methodologies that help you eliminate wasteful processes and optimize those that work well. This reduces the chances of silos and bottlenecks that could have been avoided with proper planning and automation.

#10: Happier Users

Prodly lets you implement changes for your end users faster while enhancing the quality of the product. It’s all about ensuring deployments occur correctly every time while allowing your team to optimize building, testing, and delivering the next release.

Salesforce admins have much less busy work and move through their project timelines more efficiently. Developers appreciate being more challenged with projects that fall within their skill set.

Prodly DevOps: The Most Effective Low-Code Tool for Salesforce

Low-code platforms are specifically designed so IT teams can 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. That tool is Prodly DevOps.

Interested in taking Prodly for a test drive? Schedule a demo today.

FAQs

What is DevOps?

DevOps is a methodology that enhances how you make changes to applications. In Salesforce, a growing number of declarative users are implementing Salesforce DevOps to achieve a more streamlined, bug-free, and well-documented change management process. Learn more about DevOps.

What is change management in Salesforce?

Salesforce change management involves defining and implementing a specific sequence of actions to achieve a desired change that supports a business’s overall objectives. Learn more about change management in Salesforce.

A red arrow and a white arrow coming together and merging, representing a Salesforce org merge
Data Deployment, Org Merge, sandbox seeding

Everything You Need to Know About Salesforce Org Merges

Leave a comment

Salesforce org merges are complicated but often necessary processes that involve combining one or more production instances of Salesforce. In this blog, we discuss everything you need to know about them, including what they are, what they involve, and four reasons to merge Salesforce orgs. We’ll also list what information to gather before a Salesforce org consolidation, how to prepare for a merge, and we’ll discuss how to merge Salesforce instances.

What Are Salesforce Org Merges?

A red arrow and a white arrow coming together and merging, representing a Salesforce org merge

A Salesforce org merge or org consolidation occurs when a company decides to consolidate two or more instances of their Salesforce CRM. You combine the integration of the various technological backends of these orgs into a new whole. 

Oftentimes, these orgs are highly customized, with thousands of users, a significant amount of process automation, custom objects, Visualforce pages, Apex code, third-party apps, and more. Because of this, you have to sort through everything carefully to see what’s necessary and you need to keep, what you can improve, and what you no longer need.

What Does a Salesforce Org Merge Involve?

On the surface it sounds simple, but in reality, performing an org merge in Salesforce is highly complex. To do it correctly and to the benefit of your business, you have to decide how to merge two orgs with different processes, objects, fields, data, access levels, and so on.

An org merge tends to be a period of deep reflection and reevaluation of how you’ll leverage Salesforce to support the business’s growth going forward. 

Typically, you select one of the orgs as the surviving org. However, you might choose to combine multiple production instances of Salesforce into a new org. 

Either way, parts of the legacy org often survive the process. Perhaps the legacy org had a better solution for a shared business process or solved an issue that the surviving org never encountered. That’s why you need to merge any data you want to keep from the legacy org into the surviving org.

4 Reasons to Merge Salesforce Orgs

Because org merges are so involved, companies usually only perform them for four reasons: During a corporate acquisition, to reduce technical debt, to eliminate silos between teams, and to manage costs.

1. Corporate Acquisition Org Merge

A corporate acquisition is the most common reason for performing an org merge. When one company acquires another and they both use Salesforce as their CRM, they need to integrate their systems to fully integrate the company.

After the merge, there can only be one source of truth. That’s why you designate one Salesforce production instance as the surviving org.

2. Reduce Technical Debt

Another reason for merging Salesforce orgs is to reduce accumulated technical debt. Business changes rapidly, and decisions, processes, and workarounds that made sense last year might now be obsolete. When you perform an org merge, you can select what to keep, and what to discard.

In fact, companies that have accumulated significant Salesforce tech debt after years—or even decades—of using Salesforce may find it easier to start over fresh in a brand new org than try to unwind legacy processes. In this case, they save specific processes, optimize them, and move them to the new org. This is called the Greenfield approach.

3. Eliminate Silos Between Teams

At the same time, you might have originally had valid reasons for separate business units to operate in their own individual Salesforce orgs. However, today, it could be inhibiting greater collaboration.

4. Manage Costs

An org consolidation allows you to run your business more efficiently, because you can assign tasks across groups, run consolidated reports, and have one org as the single source of truth. You can also save money on duplicate license costs for any users who need access to both original orgs; plus, you have lower costs for setting up and managing the same or similar fields or processes in both instances. 

This is ultimately a considerable cost saver. Learn more on saving on Salesforce sandbox spend. 

Information to Gather for a Salesforce Org Consolidation

As we’ve discussed, a Salesforce org merge is a considerable undertaking. That’s why it’s wise to be as organized as possible before you begin. And good organization starts with information gathering. Answer the following questions:

  • What do you hope to gain from the org consolidation?
  • How many orgs do you need to merge? What are the editions of each?
  • Do the orgs have a Classic or Lightning Experience UI?
  • How many licenses are there in each org, and what types are they?
  • Will you add to or subtract from the current number and types of licenses?
  • Which third-party applications are currently installed in each org? What are their expiration or renewal dates? Which ones will you continue to use?
  • Do you have a predetermined surviving org?
  • Does the new org have sufficient file and data storage?
  • Which data are you consolidating? All of it, or only specific records and objects?
  • What duplicate content do you need to take into account?
  • What automations and integrations are in place in either org?
  • Will you need to provide training for users post merge?
  • Do you want to preserve change histories and stage histories?
  • How will you handle private views, dashboards, and reports?
  • Do you need to preserve system audit fields?
  • If there are inactive users, how do you want to handle them?
  • Do you need to update sharing rules for the surviving org?
  • Do you need to deploy special features like multi currency, multi language, or territory management?
  • What is your timeline for the project?
  • Do you have the resources in place to handle this merge project?

How to Merge Orgs in Salesforce

Each org merge project is unique and will have specific criteria for success, but the overall process is the same. Whether you complete the consolidation yourself or hire a consultant to do it, here’s how to merge orgs in Salesforce.

1. Prepare for the Org Consolidation

A. Create a Plan

Start by putting a plan in place, along with a realistic timeline. To determine your timeline, consider both your company’s needs, as well as license expiration dates. 

It can also be useful to establish a Salesforce Center of Excellence to lead the initiative.

B. Build Your Team

Org consolidation is not a one-person job. It’s critical to engage your stakeholders early in the process. In addition, make sure that each team that will be impacted by the org is represented. 

On the technical side, you’re going to need someone who understands the data structure of both orgs. This person should be able to make recommendations on the best way to map the data from the legacy org to the surviving org.

C. Assess What Systems the Merge Will Impact

Make a list of the systems the consolidation will impact. This will include your core Salesforce Clouds, as well as:

  • Additional Salesforce Products (Pardot, Field Service, etc.)
  • Custom objects
  • Apps from the AppExchange
  • Integrations to systems outside Salesforce (ERP, sales engagement, advertising platforms, web-to-lead/case forms, etc.)

D. Document Requirements

With all the information from the previous section  at your fingertips, it’s time to list out the requirements for the org merge. Think also about things such as the length of time you’ll need to store data from the legacy org that you’re not consolidating, how processes will change, and what your testing plan is.

E. Create an Org Merge Strategy

You absolutely need a strategy to effectively complete the consolidation. Due to their complexity, org merges take time and multiple sprints. However, that doesn’t mean all work in production grinds to a halt.


Determine which sandbox to use for staging the org merge before deploying it to production. How will you keep the staging environment current with changes and hotfixes in prod? Do you have an easy, repeatable way to seed the sandbox with data (and possibly even metadata) without having to do a refresh that overwrites the org merge work in progress?

2. Build Your ETL Logic

ETL (extract, transform, load) is the process of taking data out of one system, cleansing it, and moving it into a new system. Mapping out your ETL logic is the key to a seamless org merge, so make sure to allocate this step the time and attention it deserves.

A. Map Objects Between the Two Orgs

Start by mapping objects between the surviving org and legacy org. Which objects do both orgs have in common? Which legacy objects will need to be mapped to existing objects in the surviving org? Will new objects need to be created in the surviving org so you don’t lose data?

Also, consider which objects should use audit fields for accurate reporting. For instance, if you’re not careful with Opportunities, you could make it appear that you created and closed the legacy Opportunities on the same day. This would completely invalidate your average sales cycle.

B. Check Field-Level Mapping

Now you’ve mapped the objects, it’s time to think about field-level mapping. Now the objects match, do their fields? 

If not, is the data needed in the surviving org? If so, should the field be mapped to an existing field or recreated in the surviving org?

Pay attention to picklist values and any data standardization in the surviving org. Loading incorrect formats or values will impact reporting, validation rules, and general user experience. 

For example, let’s say the surviving org uses Enterprise Territory Management to assign territories based on a two-letter state or province code. In this case, the legacy values should be transformed before loading, otherwise the legacy accounts won’t be assigned correctly in the surviving org. 

3. Execute the Org Merge

With all the preparations complete, it’s time to perform the actual merge process. Remember: You’ll need to keep the legacy org operational until you’re ready to fully transition users to the surviving org. This means you’ll have to run through the org merge steps multiple times to make sure you’ve caught all new and updated records.

A. Steps for Executing an Org Merge in Salesforce

Perform the following steps to carry out the org consolidation process:

  1. Provision a sandbox from your surviving org, seeding any data from the surviving org if needed.
  2. Configure any new objects, fields, and apps that you need in the surviving org.
  3. Extract and load your legacy data into the sandbox, transforming it per your ETL logic.
  4. Test, test, test! This should include unit testing and UAT in the sandbox. 
  5. Train users on any changes to processes.
  6. Deploy your metadata changes and records to production. 
  7. Review all deployments. Remedy any errors, and redeploy if necessary.

Congratulations! You have successfully completed the org merge!

A Final Word

Keep in mind that the type of integration needed and your stakeholders’ requirements will dictate when you can start making changes. The earlier you can transition integrations that create or update records, the fewer times you’ll have to run through the org merge process. 

However, this isn’t always possible. For instance, you can’t update your legacy web-to-case forms until you have users who can resolve customer issues actively working in the surviving org. 

Prodly DevOps can help seed your sandbox, as well as automate the entire work migration process quickly and compliantly during an org merge. Check out our FREE on-demand webinar, Easier Org Merges, to see how we can help you prepare and perform your next org merge. 

FAQs

What is a Salesforce org?

A Salesforce org is a dedicated instance of the Salesforce platform where you store and manage your organization’s data, configurations, and customizations. Each org has its own set of users, data, and security settings and can be customized with various apps, objects, fields, workflows, and integrations.

 

How does a Salesforce org merge reduce technical debt?

When you consolidate two or more Salesforce orgs, you can significantly reduce technical debt by consolidating data, reducing the number of customized components you need to maintain, and minimizing the number of apps and integrations you need for your surviving org to function optimally. Learn more about technical debt in Salesforce.

Sand dunes representing populating sandboxes with data
Release, sandbox seeding

The basics of Salesforce sandbox seeding

Leave a comment

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 Sandbox Management 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.