Update Automations
Learning Objectives
After completing this unit, you’ll be able to:
- Migrate workflows to Flow Builder.
- Remove field-automation dependencies.
- Deprecate inactive automations.
Modernize Workflows
Security gaps are closed. There’s a single source of truth when it comes to cases and case data. Most of the duplicate fields have been addressed except for those that are tied to workflows.
While we’re on the topic of workflows, you’ve discovered several things.
- All workflows for AW Computing use the legacy automation tool Process Builder.
- Some processes are inactive with little context as to what they were for.
- There’s an active workflow that emails teams about high-priority cases, but all those emails are now routed to spam folders because it got too noisy.
How do you go about managing all these items?
Make It Make Sense
Just because an automation (or any setup for that matter) is inactive or ignored, doesn’t mean it’s useless and should be removed. It’s important to inquire why it was set up in the first place—perhaps there’s a use case no one is thinking about.
Sometimes you can track down who created the field or automation and ask them directly. Sometimes, an org has been around for a while and you need to do some detective work by checking with stakeholders and reviewing metadata.
That’s the case with AW Computing. The service team members you’ve been working with have been great stakeholders, and they give you the go-ahead to delete the inactive and incomplete legacy workflows. They also want you to update the high-priority case email alert in Flow Builder if you can make it more meaningful.
Migrate to Flow
The use case for the active workflow turned out to be valuable, albeit poorly executed. The original alert became spam because it sends an email whenever a case is set to high priority. The problem is, there are too many reasons why a case can be set to high priority.
A better signal is if the case is dangerously near SLA violation. You can set this workflow to alert teams when a case is at risk of violating SLAs instead, and request a swarm.
Your first step is to migrate it to the modern automation tool, Flow Builder.
- From Setup, search for and select Migrate to Flow.
- Select the workflow you wish to migrate.
- Then, click Migrate to Flow.
- Check the box next to the criteria that should be migrated.
- Then, select Migrate to Flow.
The migration process creates a new flow that’s set to inactive, so that it’s available for you to tweak and test as needed before deployment.
Update the Flow
Next, you update this flow to ensure the alert goes out when it’s really needed.
- From Setup, search for and select Flows.
- Select the flow you wish to update.
- Click on the Record Trigger element to expand it.
- Then, select Edit.
- In the existing Field, click X to remove it.
- Replace it with the desired SLA field.
- Click into the corresponding Value field and select the value from the dropdown options.
- Next, select Save As New Version.
- Then, select Save.
- When this is done, select Activate.
Delete the Inactive Flow Version
You created and saved a new version of the flow. Usually, maintaining flow versions is important—it allows you to go back to reference previous iterations, pull things into a newer version, and so on. However, the previous version that you migrated from Process Builder included relationships with duplicate fields. You won’t be able to remove them without first deleting the inactive version of your flow.
- From Setup, search for and select Flows.
- From the show actions dropdown
to the far right of the flow you wish to manage, select View Details and Versions.
- Then, select Del next to the inactive version of your flow.
- Select OK to confirm.
Deprecate Active Workflows
Now, deactivate the legacy process and remove any trace of workflow clutter.
- From Setup, search for and select Process Builder.
- In Process Builder, next to the active process, select the Show All Versions arrow
.
- Select the process name to open it in Process Builder.
- Select Deactivate.
- Then, select Confirm.
- Next, select Back To Setup.
- Search for and select Process Builder once more.
- Next to the processes you wish to delete, select the Show All Versions arrow
.
- Then, click Delete.
Clean Up Remaining Dupe Fields
There were several fields that you couldn’t delete because they were connected to these workflow and email alerts. Now that the workflows have been taken care of, all that’s left is to decouple the fields from the email alerts and finally delete the fields.
Delete Legacy Workflow Rules
- From Setup, search for and select Workflow Rules.
- If you get an informational page Understanding Workflow next, check the box so the system doesn’t show you this page again and select Continue.
- If you get an informational page Understanding Workflow next, check the box so the system doesn’t show you this page again and select Continue.
- Then, select Del next to the rule you wish to remove.
Delete Legacy Email Alerts
Similarly, you remove legacy email alerts.
- From Setup, search for and select Email Alerts.
- Then, select Del next to the alert you wish to remove.
Delete The Rest of the Duplicate Fields
Now you’re free to remove the remainder of the duplicate fields.
- Head back to Setup.
- Select Object Manager.
- Find and select Case.
- Select Fields & Relationships.
- Select the dropdown next to the field you intend to delete and select Delete. A popup shows important information about exporting your data and how long fields will be available for restore.
- To confirm, select Delete.
You Did It!
You report back to the services org and the M&A team. The last bits of tech debt have been managed. Congratulations!
In this badge, you managed technical debt–from security risks to duplicate fields to legacy automation. You took a strategic approach, prioritizing tech debt by risk, just like you would in a real world scenario. While no org is the same, the best practices you learned here can help you tackle whatever tech debt is in front of you.