Salesforce recently announced “end of support” for Workflow Rules, a long-time automation feature beloved by admins. It’s easy to be alarmed, but we’re here to explain what it means for you, and how you can prepare your org for the transition, and even come out better in the end!
What does this mean?
When Salesforce announces end of support, it means they will not support that feature any longer. Does this mean your workflow rules stop working on the end of support date? No, they will keep on going. What it does mean is that if you run into an issue with your workflow rules, and you log a case, Salesforce will close the case as “not supported”. While that may seem a little scary, if you have workflow rules that have been chugging along for years, you will unlikely encounter any issues when end of support occurs. Previously, Salesforce prevented users from creating new workflows in an effort to encourage folks to move to Flows. If you are relatively new to Salesforce, you may not even have many workflow rules present in your org at all.
What about packaged workflow rules?
If you are using a package such as Nonprofit Success Pack, there may be workflow rules in your org that were installed by the package. These workflow rules will continue to work. However, if you prefer, you can mark them as “Inactive” and re-create their logic as Flows.
What’s so great about Flow?
It’s up to 10 times faster, so if you are importing files or have any integrations that trigger your workflows, Flow will speed things up. There is also a lot of flexibility around entry conditions, to ensure that it is only running when necessary.
I have workflow rules in my org, what do I do?
We recommend that even though your workflow rules will continue to fire, you should probably consider migrating them to Flow at this time. When Flow was first introduced, it required a technical person to implement it. Salesforce has improved its usability, so it is easier to get started. Migrating your Workflows to Flow is a wonderful opportunity to re-examine your processes and streamline them where possible. For example, you may discover that as many as 5 different workflows are running on the Account object, with a variety of filters and steps. By examining your workflows, you may discover that these can be consolidated into a single Flow.
This is a great time to review all the potentially conflicting workflows (we recommend a diagramming tool like Lucidchart or Miro, or even a whiteboard). When you can see all of the different rules acting on the same object, it can become clear quickly how you can streamline your processes. Of course, you’ll want to make sure you get buy-in and discuss processes with your team. Are there items that the team has wanted to automate? Are there automations that are no longer necessary because business processes have changed? Make sure that the old processes are mapped out before mapping new ones to Salesforce. Once you have a before and after diagram, you can begin translating it into Salesforce.
But what if I’m nervous?
What’s great about Salesforce is that every org has a sandbox where they are able to create new Flows and test them thoroughly before launching them in production. You can create new Flows or update existing Flows in a sandbox environment. In a sandbox, test turning off the Workflows and only using the Flows. Do the Flows behave as expected? Do you encounter any errors? If so, you can troubleshoot in a sandbox until you are sure that they are ready to move to production.
If you are retiring a lot of Workflows at once, even if you have the complete (new) process mapped out, create the first “slice” of automation and test it in a sandbox. Then add the other layers of complexity to ensure that each piece works as you add it to the Flow. This will prevent headaches from building a large complex Flow and testing everything at the end.
I’m not technical, this seems complicated!
Great news! Salesforce has created a migration to Flow tool that does a lot of the work for you. There are some limitations to the types of workflows that are supported, which you can read about here. For the most basic workflows, it can be as simple as clicking the “migrate to Flow” button and testing it out. There is also a project in Trailhead which allows you to try it with a Trailhead playground and managed package, so you can gain confidence with it before attempting it in your own org.
Make sure that you take your time, and try to focus on one object at a time. As you work your way through your list, you will gain confidence and be on your way to becoming a Flow expert. If you could use some extra help migrating your workflow rules, get in touch with us to make the move to Flow.