Email-to-Flow is available on the Salesforce Appexchange.
I love Email-to-Flow! I can finally control our complete Email-to-Case process… from Flow! My flows, however, are getting more complicated and more difficult to maintain. You have any suggestions?
I recently received the above cry for help from an Email-to-Flow client. Their story, sadly, is not unique. The client initially embraced flow for its ease of use and ability to handle completed business requirements. With little controls surrounding their flow development, their once easy to maintain flows morphed into FlowArt.
What’s FlowArt?
That’s what we call flows that are beautifully complex and fun to look at…. and near impossible to decode.
Take a picture of it. Stick it on the fridge… right next to your child’s macaroni self-portrait. We will all stare in amazement. We may even utter an “ooh” or an “ahhhhh”.
But please don’t ask us to “just make a quick change”. In a typical FlowArt scenario, only the original author has a chance of successfully navigating a change to the logic… which defeats the reason for being a flow in the first place.
FlowArt is NOT good Flow Design
Flows should be clear, concise, and scalable. Period. Unclear and overly complicated flows lead to bugs and technical debt.
For any developers reading this post, FlowArt is the equivalent of a developer creating thousands of lines of code in a single method.
Avoiding FlowArt
There are many, many, many ways to avoid FlowArt, including good design, complete documentation, the use of invocable methods and the use of subflows. Search the web or Trailhead and you will find a lot of great best practices content for Flow development.
Today, I’d like to focus on a not so common approach – the rules engine.
The Use Case
In our client’s use case, we highlight a scenario begging for a business rules engine.
NOTE: For simplicity, we scaled down the example significantly.
The flow implements a Spam Detection process. An email is identified as spam if:
- An email has a Spam Confidence greater than 5
- An email contains one of the common spam phrases
- An email has a Bulk Confidence Level of 7 or more
- An email domain is “fake.com”
If identified, the case is flagged as spam and sent to a Spam Queue.
The Business Rules Engine Implementation
Introducing the BREeze Business Rules Engine
For our business rules engine, we leveraged BREeze (available for free on the AppExchange). With the BREeze UI, we defined a single rule to accommodate our use cases.
NOTE: For simplicity, we scaled down the demonstration significantly.
For example, Rule #1 defined out first requirement. If the Spam Confidence Level is great than 5, we assign the following case values:
- Case Type = Spam
- Case Owner = Spam Queue
- Case Priority = Low
Modify the Flow
Next up, we modified the flow. We replaced the 4 decision nodes with a single Email-to-Flow Execute BREeze apex action.
The Execute BREeze apex action includes two input values:
- The Case object
- The BREeze Rule Name
The Execute BREeze apex action includes three output values:
- IsSucess – an indicator that the BREeze functionality completed successfully
- Error – the error message in the event of a failure
- Update Case Record – the updated case object
Enjoy
Deploy and enjoy. That’s all there is to it.
As an added bonues, rules can be modified easily in the UI. No flow changes are required.