Tag Archives: tech debt

An abstract image signifying migrating workflow rules and process builders into flow
Best Practices, Flow

How to Manage Old Workflow Rules and Process Builders

Leave a comment

Is Migrate to Flow Really the Best Solution?

Salesforce recently introduced the new tool Salesforce Migrate to Flow because it’s retiring Workflow Rules and Process Builder in favor of Flow by 2023. But using this tool isn’t always the best solution.

In this blog, I explain how best to manage old Workflow Rules and Process Builder automations using Salesforce’s tool, as well as using Prodly DevOps.

When to Use Migrate to Flow

An abstract image signifying migrating workflow rules and process builders into flow

With Migrate to Flow beta, Salesforce ironed out some of the issues admins ran into with the initial version of the tool. That said, because of the way the tool works, it’s really only appropriate for automation with a single, simple Workflow Rule—otherwise it can cause problems.

Migrate to Flow Can Cause Problems

It’s best practice in Salesforce to have as few Flows as possible.* You want to consolidate as much as possible for ease of maintenance, as well as for system resource usage.

Important

*Note that while it’s generally desirable to incorporate as many processes as possible in one automation to minimize your number of Flows, there’s an exception to the rule:

If your business users frequently request changes to specific Flows, it can be helpful to segment longer business processes into several shorter Flows with a smaller number of processes. That way, they’re easier to edit, and there’s less chance of breaking something.

Complex Workflow Rules

Unfortunately, with Migrate to Flow, Salesforce hasn’t provided a very effective solution for more complex Workflow Rules.

Let’s say you have 15 different Workflow Rules that need to be consolidated into one or two flows. The Migrate to Flow tool can only create one Flow for each Workflow Rule.

That means you wind up having 15 Flows. Now, if you have 15 Flows taking place when a transaction happens, Salesforce won’t guarantee the order in which they take place—and that could cause problems.

Let’s say an email notification goes out when a field is updated to red. If all the Flows take place at the same time, the field color won’t be updated in time to trigger the email. As a result, critical parts of the process might not be completed.

Why Manage Automation Migrations with Prodly DevOps?

While Salesforce has provided a tool to migrate workflow rules, that tool doesn’t yet work for Process Builder automations. As a result, you still need to figure out how to migrate those.

To save time and frustration—and to work in the most efficient manner—it’s advisable to consolidate all declarative automation into Flow in one fell swoop.

Because you can’t just turn off an automation in production, you’ll want to build and test the new Flow in a sandbox or scratch org. Then you can use Prodly DevOps to effortlessly deploy the changes back to production.

With Prodly DevOps, you can streamline the process in the following ways:

Easily Migrate Metadata Up the Release Pipeline

Prodly DevOps lets you easily compare metadata differences between orgs to ensure you’re moving exactly what you want to. Then, using Prodly’s automation, you can quickly migrate the metadata up the release pipeline.

With just a few clicks, you can move your newly configurated Flows from your scratch org or Developer sandbox to integration, testing, staging, and ultimately to production.

Effortlessly Audit Your Changes

In Migrate to Flow, you can see who changed a configuration, when, and how. But if you’d like an audit report of the changes, you’d have to query it and export the results to Excel.

In contrast, Prodly’s compliance feature automatically tracks every change you make and lets you easily create an audit report—with exactly the information auditors want to know about.

Maintain Reasonable Tech Debt

If you understand and care about systems, you want to minimize technical debt. Now, if you were to use Migrate to Flow to move the 15 Workflow Rules I discussed earlier, you can’t consolidate them into one Flow. Instead, Migrate to Flow creates a whopping 15 Flows. That’s a lot of tech debt you don’t need.

And then you still have to figure out how to migrate your Process Builder automations.

Prodly DevOps facilitates governance. That means if you’ve committed to consolidating your declarative automation in one go, you can use the opportunity to look at your processes and evaluate what is and isn’t working. Then determine how you can solve the problem more efficiently—saving yourself a ton of tech debt and headache down the road.

Stay Within Your Change Management Process

Depending on your company, you might have very strict governance requirements in place. Sometimes, that makes using a new tool like Migrate to Flow extremely challenging because it hasn’t yet been approved.

With Prodly DevOps, you can use the same metadata migration process as you always do without going outside of your approved change management process.

Consolidate Declarative Automation With Prodly DevOps

To see how easy consolidating old Workflow Rules and Process Builder automations becomes with Prodly DevOps, just request a personalized demo.

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

Managing technical debt in Salesforce
Best Practices

Managing Technical Debt in Salesforce

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.