I recently came across one of the most complex workflows I've ever encountered. After the initial cringe and urge to run away I wanted to understand what the business case was. It turns out that a lot of the activities were decision points to determine which user(s)/group(s) should approve the request based a number of options on the request. To be honest, I didn't look at the entire workflow, it would have taken hours to get my head around it.
My initial gut response was to recommend splitting the nearly unmanageable flow into multiple subflows. This would make it easier to visualize, update, and troubleshoot. Plus the risk of change impact could be reduced to the scope of the subflow. Once I understood the multiple levels of decision points, I had a better recommendation that is an all-around good practice to follow in workflows or any scripted automation throughout the platform.
Whenever you are hard-coding a decision you need to think about the long term impact of supporting that configuration as well as scaling the solution.
Scalability
Let's start with the scalability concern. Say you have a scripted switch statement, nested ifs, or workflow decisions based on field/variable values. Even though it may only be a few options today, what are the possibilities that it could grow in the future to a dozen or more? Every time the decision tree changes you need to add more lines of code or additional workflow conditions and activities.
Support and Management
Hopefully the scalability concern already has you thinking about things you might have already built or have planned to build. That's a great start. However, the bigger concern I usually have is the cost and risk of on going management and support. If the business defines specific needs such as; for a given category they want a specific user/group to approve, you can count on this changing at some point. They will also most likely add/remove categories as they start to see value in the automation. Yeah, I know the process owner said it won't change much and I know the customer is always right. Most likely not this time, sorry process owner.
When you need to make a change to a complex workflow or script with numerous hard-coded decision values it can drastically increase the level of risk for what seems like a relatively simple request. This increased risk could impact the priority, timing, and test cycle needed for the request. It's tough to explain to the process owner that by simply adding another category:approver mapping requires a change control, and testing from various parties to make sure we didn't screw up something else in the process. "I thought you had this awesome cloud automation platform, why does IT have to be so freakin hard?"
Not only does the process owner have to submit their request to the admin team, they have to wait for the entire review/approval/build/test/deploy cycle to be completed before they can leverage the change.
Solution
So what's an admin to do? The ideal solution in most cases is to remove the hard-coded decision points from the script or workflow and store them as data. For example, in the simple case of determining the approver from a category, instead of an increasing number of workflow activity conditions or script case statements, you could have a simple script that looks up a record where the category matches and retrieves the approver value. Yes, it will slightly complicate the workflow approval activities initially since you'll need to use a script instead of hard-coded approvers if you can't dot-walk to the data, but it provides a more scalable solution in the long run. The other major benefit of moving the decision matrix to data is that you can now delegate management of the data. If the process owner needs to change who the approver is, then grant them access to the table and let them implement their own change process. Since there's no change to the automation configuration there is no need for admin involvement or major change management process delays. Ultimately this leads to a better customer experience and you spend less time managing their business process changes.
Also don't forget about even more simple solutions such as using reference fields so you can dot-walk to get to the data points you need. There's also data lookup and record matching features that will help propagate record fields based on the values of other fields. The custom data tables mentioned above are recommended when the simpler solutions don't fit the need.
Happy automating and enjoy the free time you will get back when you think like an architect.
7 Comments
