Tag Archives: governance

Best Practices

Managing Technical Debt in Salesforce

April 1, 2022 Hayley Coxon Leave a comment

Deploy releases faster—and boost your Salesforce ROI

What to know:

Bad technical debt impedes your release process and the health of your orgs—hindering your ability to conduct business.
Good tech debt allows you to release changes faster—making you more agile and more responsive to opportunities.
Almost 75 percent of businesses that report a very high ROI from Salesforce have a continuous or fast release cycle.
Leveraging an agile approach to change management in Salesforce allows you to detect and address problems early on in the project while releasing incremental changes faster.

What Is Technical Debt?

There are two kinds of tech debt in Salesforce:

Bad tech debt is the cost of rework resulting from a rushed development process with siloed participation from team members—instead of using a better approach that would take longer to develop.
Good technical debt pertains to the amount of work you need to invest now or in the future to ensure a streamlined, continual process that yields good results.

In this blog post, I’ll examine the cost of bad tech debt, what causes it, and how to fix it. I’ll also discuss the value of good tech debt and how to ensure it.

The Cost of Bad Technical Debt

Picture the following scenario: In your prod org, there’s a custom object that’s… well, let’s just say it’s delicate. Every time you need to add a new item or delete a custom field, you run into problems that slow down processes—or worse, crash the org. As a result, nobody wants to touch the object. And that affects your ability to fulfill requests and obstructs your business process.

This is an example of bad technical debt that’s most likely the result of not investing sufficient time in the steps needed to achieve a clean process. And it’s understandable, considering it’s often challenging to balance priorities when you’re constantly under pressure from users to provide new functionalities.

Unfortunately, when bad technical debt becomes too great, it significantly delays releases. In some cases, businesses wind up throwing the org in question away and starting over from scratch. Either way, it’s detrimental to your business’s responsiveness—not to mention frustrating for your team and users.

What Causes Bad Tech Debt?

Bad technical debt can be caused by several factors, including:

A lack of ongoing data model design and refactoring resulting from not having an established process to create new and update existing data models.
An over-reliance on programmatic customization, or worse: by poorly-written Apex and Visualforce pages causing bugs that can slow processes down and even crash your org.
Leveraging bad coding practices when there are readily available configuration options.
Poor data quality that leads to failed deployment and app crashes.
Irrelevant integrations that are performing actions you’re not even aware of.
Letting good tech debt build up for too long.

How to Minimize Bad Technical Debt

You can minimize bad tech debt by trying not to incur it in the first place. It may be tempting to jump straight to Apex to solve a problem, but don’t overlook long term maintenance costs of custom code solutions. Instead, push Salesforce’s point-and-click solutions to the limit, as the maintenance cost of supporting falls to Salesforce—not you.

If you do find yourself buried in technical debt, it’s possible to dig yourself out. First, you’ll need to understand the scope of the debt. Start with an org audit, and use tools like Salesforce Optimizer, Field Trip, or Metazoa to go faster. I find it helpful to go object by object, starting with the most commonly used ones. Old record types? Fields that are not being used? Validation rules whose origin you can’t trace? Mark it all down. The goal at this stage is just to get a clear picture of what’s going on.

Next, figure out a plan of attack. It’s not possible to fix everything at once, so address issues in order of importance. What’s causing the most impact to users or breaks most often? What’s the biggest blocker to passing code coverage?

Be prepared—tech debt can be a tangled mess. Pulling on one thread may mean you need to unravel a few others. Don’t be discouraged. Steadily making progress on reducing tech debt will pay off. And when you’re most frustrated, knock out a couple of your pet peeves. (Mine? Page Layout sprawl).

Finally, establish policies and processes to prevent your org from winding up in this state again. That should include setting standards for documentation. Your future self will thank you.

The Value of Good Tech Debt

Let’s say you want to roll out a new flow for your users. Now, you could create a plan that requires you to get the complete flow with all its bells and whistles up and running in a few weeks—but the chances of bugs and errors due to going too fast are very high.

So instead, you design a project plan that includes the steps to initially build and deploy the basic flow, and then add additional features once that’s live. The plan gives your team sufficient time to complete each step, work out the bugs, and get each new iteration up and running so your users are happy and the flow drives increasingly more value for your business.

As this example shows, the value of good tech debt is that it enables faster releases—which in turn yield greater ROI from Salesforce. Research shows that 73 percent of study respondents with very high ROI from Salesforce have daily or continuous release cycles. In contrast, only seven percent of those with quarterly, bimonthly, or monthly release cycles cite a very high ROI.

How to Ensure Good Technical Debt

Good tech debt in Salesforce comes from leveraging the iterative process of agile. As we’ve seen, fast release cycles drive Salesforce ROI—but velocity shouldn’t come at the expense of org health.

You should optimize your release management practices to minimize bugs and errors that result from cutting corners in the name of speed. Leveraging an agile approach to change management allows you to detect and address problems early on in the project while releasing incremental changes faster. (Read more in The Ultimate Guide to Salesforce Release Management.)

So you need to build out an initial project, release it, and—critically—complete optimizations plus add additional features later. Note that if you don’t complete your backlog, you’re building up bad tech debt.

Keep these tips in mind to ensure good tech debt:

Promote collaboration and coordination to implement uniform processes team-wide for data model design and refactoring.
Avoid over-customization resulting in bad code that doesn’t pass Salesforce’s minimum validation threshold to promote your changes.
Leverage available “clicks, not code” configuration when possible to avoid unnecessarily adding code that could adversely impact processes.
Keep data and validation rules up to date to prevent delayed processes or even downtime.
Regularly review integrations and managed packages, and make a plan to decommission old, unnecessary integrations out of your org.
Adhere to a policy that documents all changes to an org so you have a history of modifications you can refer to in the event you need to troubleshoot.

Prodly DevOps for Good Tech Debt

You can also leverage automation to help ensure good tech debt. The Prodly suite includes the next-gen DevOps solutions Prodly Sandbox Management and Prodly DevOps. They enhance and streamline change management in Salesforce by automating data and metadata migration, sandbox seeding, and sandbox management.

Because these solutions eliminate manual labor in data and metadata migration, they’re 100% accurate, which minimizes rework due to errors and bugs. They reduce data migration time by up to 85 percent and deploy metadata 12 times faster than change sets. As a result, you gain more time for higher-level work, which enables you to ramp up your release cycles—and drive your business forward.

To learn how your business can benefit from the Prodly suite, request a demo.

Abstract image composed of swirling particles

Best Practices, Data Deployment, Release

Best Practices for Data Migration in Salesforce

March 31, 2022 Reese Bernier Leave a comment

Many Salesforce professionals find it challenging to migrate data between environments. By keeping the following tips and best practices for data migration in Salesforce in mind, you can streamline your workflow and enhance your chances of getting the deployment right the first time.

Top Tips for Salesforce Data Migration

The complexity of migrating data between orgs depends in large part on the volume and types of data you need to deploy. These tips will help you stay organized so you can optimize your Salesforce data deployment process.

Preparation

Preparation is key. Especially if you’re migration a large volume of data in Salesforce, budget sufficient time to prepare for the data migration to ensure the success of the deployment. Add some extra time in case you run into issues, then:

Make a backup of the data in case something goes dramatically awry. That way, you can restore the original data immediately and continue business as usual.
Determine the purpose, scope, and timeline of the migration. Your understanding of these details will guide your actions throughout the rest of the process.
Create a robust data governance plan. Data governance is critical to ensuring the continuous integrity and value of the data. Develop a data governance plan to pinpoint how to manage data before, during, and after the migration. Assign roles and responsibilities. Then establish how to validate data before storing it, and outline a policy for the storage of legacy data.

Migrate the Metadata

Begin by cleansing the data to eliminate outdated accounts and duplicates from the migration.

Next, sample the metadata from the source org(s) to determine how the data is structured. Then map the objects, fields, and values from the source environment to the objects, fields, and values in the destination org.

The difference between the data model structures in the source and destination environments governs how complex the data mapping process is.

Make sure to double check the fields in Salesforce. All the data you want to include needs to have a corresponding field in the destination org.

Migrating the Data

Once you’ve successfully moved the metadata, you can migrate the data into the new environment:

Use a single source of truth. Identify which data to migrate to the destination environment by first determining which data is accurate.
If applicable, mask data to protect personal identifiable information (PII), sales revenue, or other sensitive data. Salesforce Data Mask lets you mask the data in an environment when using Sales Cloud, Work.com, Service Cloud, AppExchange applications, Salesforce Industry products, and platform customizations. This is critical for security and compliance purposes in many industries.
Create checklists. If you’re using a data migration tool like Data Loader or Dataloader.io, make lists of all the fields you need on your spreadsheets. With Salesforce ETL tools, it’s also helpful to create a list of how to load the individual files. For example, begin with the Parent Object, then the Child Object, etc. Also list any data manipulation that needs to be performed between steps.

Migrating Relational Data

Relational data is typically challenging to migrate properly because relationships between records can be extremely complicated. Follow these steps to maintain complex relationships:

Ensure all records in the source system are assigned a unique ID. Then map related records to the relevant parent IDs. For example, if you’re moving Contacts, make sure they’re linked to their Accounts so that when you migrate them, the entire context is imported. This will allow you to look up the matching account for contracts with the unique ID, since Salesforce record IDs will change during data migration.

After Checking Relational Data

After checking the relational data:

Make sure the data types are correct. Ensure there aren’t any letters in fields that require a numeric value, for instance.
Decide if you need to use audit fields for each record. If knowing who originally created the record or when it was originally created is desired, turn on audit fields. Load the data in the proper order to maintain data dependencies. Always load the parent record first—for example, load the Account first and then the Contact.
Validate the migrated data. Validate record counts and spot check the data by creating custom reports. To check if any data wasn’t migrated, review exception reports.

Benefits of an Automated Data Migration Tool

Data Loader, Salesforce’s free tool, and Dataloader.io both involve a significant amount of manual labor. On top of that, they’re time consuming and error prone. They’re also far from secure because you have to export the data from the source org to CSVs on your computer.

In contrast, Prodly is a user-friendly, “clicks, not code” data migration tool that leverages automation to do the heavy lifting for you.

With Prodly, you can migrate as many records as you want—including complex relational data loads—to up to five orgs at once. Note that the solution eliminates many of the manual steps needed with Data Loader and dataloader.io.

You can review the results of the deployment with a single click.

Effortlessly Ensure Compliance

Moreover, the data migration software automatically tracks every change you make so you can effortlessly ensure compliance. In addition, because you don’t have to download any data to your desktop, the solution is just as secure as your Salesforce environment.

Enhance Productivity by 80 Percent

With Prodly, you can reduce the time you spend on data migration by 85 percent—and enhance productivity by 80 percent. You can greatly improve your agility and velocity. As a result, you can capitalize on new opportunities and advance your business faster than ever before. For more information about Prodly and to request a demo, please contact us.

Enjoy this blog? Sign up now—and be the first to know when we publish something new!

Sandbox Management, sandbox seeding

The Value of Bidirectional Sandbox Seeding

August 30, 2021 Hayley Coxon Leave a comment

In this blog, we explore what bidirectional sandbox seeding is and why you need it. We also look at the value of sandbox seeding with Prodly Sandbox Management, as well as why you should be seeding sandboxes in the first place.

What Is Bidirectional Sandbox Seeding?

Bidirectional sandbox seeding involves deploying data from your production org to a sandbox—and from your sandbox to another environment. You can do this with a freshly created org or during an environment refresh.

Why Do You Need Bidirectional Sandbox Seeding?

Bidirectional sandbox seeding allows you to create a fresh sandbox, deploy data to it, and then move data in any direction—up, down, and laterally. You can roll back changes to start all the way at the beginning, or you can change just one tiny detail.

This makes for a much better auditability of changes in production and deployment results, resulting in better governance.

When you’re only able to work with partial data, the chance of bugs and errors slowing down your progress is immense. Many teams lose steam in the development and QA process when they go the route of manually working with a sandbox test data set.

In contrast, bidirectional sandbox seeding gives control to anyone who can click through a data management workflow.

The Value of Bidirectional Sandbox Seeding With Prodly

With the sandbox seeding feature in Prodly Sandbox Management, you have the ability to move data in both directions—with just a few clicks. This allows you to maximize your team’s efficiency, transform your entire workflow, and improve your end-user experience.

By using this low-code option for DevOps, you’ll soon be handling change requests like clockwork.

Improve Your Governance Strategy With Prodly

The seamless, automated process for seeding sandboxes Prodly provides enhances your governance strategy.

It increases org health, fights errors, and improves efficiency tremendously. Here’s how:

Prodly Sandbox Management can help you move your data up, down, backward and forward between your production org and sandboxes.

It gives you the power to migrate data from up to five orgs simultaneously. This eliminates the need to depend on a Full Copy sandbox to work from as you advance through changes.

You can also configure data simulations, meaning that you can make changes without consequences. When you need to deploy complex data from a schema all at once, you don’t have to worry about complications anymore.

Sandbox Seeding Without Prodly

Without the sandbox seeding feature in Prodly Sandbox Management, you’re literally left to your own devices having to use a barrage of tools to handle what Prodly does seamlessly.

There’s the tedious process of using a data loader. The difficulty, duration, and mind-numbingness of the project can be compounded based on the size of your project.

Some companies employ a third-party developer to manage their sandbox, which can become quite costly.

In contrast, with Prodly, you can populate—and even anonymize— representative test data into as many as five orgs in just a matter of minutes. Prodly gives you more control of your data and processes, as well as a greater probability of aligning your team with the needs of your stakeholders for every project.

Why Should I Seed Sandboxes?

There are several very good reasons to seed sandboxes.

Without sandbox seeding, there’s a lack of representative production data in lower-level sandboxes that makes it harder to imagine, configure, and test changes.

This problem becomes more complicated as changes move up the release pipeline and you need to keep all of the sandboxes in sync with production.

However, sandbox seeding lets you provide everyone with their own development environment before they promote their changes to a shared QA org and ultimately production. This circumvents the problem of who’s doing what in a shared sandbox—plus, it reduces the odds of overwriting each other’s work.

It lets your team work faster and test more thoroughly. It also gives you more effective use of your expensive sandboxes.

In addition, when everyone has their own development environment with representative data, it’s much easier to find a good window of time to refresh your Full Copy or Partial Copy sandbox. And that in turn reduces the number of errors you encounter during the development process.

See Bidirectional Sandbox Seeding in Action!

Discover how easy and quick it is to seed sandboxes with Prodly Sandbox Management—watch the 25-minute webinar Ask a CSM: Bidirectional Sandbox Seeding.