Data migration
October 11, 2022
How to manage old workflow rules and process builders
Is migrate to flow really the best solution?
.jpeg){kind=avatar}
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.
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.
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.
*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.
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.
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:
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.
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.
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.
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.
To see how easy consolidating old Workflow Rules and Process Builder automations becomes with Prodly DevOps, just request a personalized demo.
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.
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.
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.
*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.
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.
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:
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.
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.
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.
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.
To see how easy consolidating old Workflow Rules and Process Builder automations becomes with Prodly DevOps, just request a personalized demo.
.png)