How long should your workflows run?

Blog Post created by weitkae Employee on Mar 30, 2017

There are a lot of answers to that question, and some are better than others. A workflow that automatically makes a decision based on logic may run for less than a second. Another workflow requiring a person to make a decision may run for about a week. A third workflow asking four people to make a decision may run for over a month.


But how long is “too long” for a workflow to run?


Take the Acme HR workflow that keeps track of reviews as an example. It starts when a person is hired, and runs for 30 days before notifying that a review is needed. At 60 days it announces another required review, and again at 90 days. This runs well in a pilot test, so an annual review reminder is added and it’s rolled out to all 700 employees.


Now you have a problem: 700 parallel workflow instances, each checking the HR database every .5 seconds to see if the date of hire for their subject is 30, 60, 90 or any multiple of 365 ¼ days ago, and they all need to run for years uninterrupted by software updates, bugs, and system changes.

One solution is to reconfigure the workflows to track by manager instead of employee and add a 1,000 x time delay to a cut down on the license use. Now you have 100 parallel workflows running every 5 minutes year after year, and you need to account for staff reorganizations in the workflow.


Maybe a better solution is to think sideways from the business process. Instead of a set of workflows that align with the review process running endlessly, try designing one workflow that runs once a week and checks the calendar against all employee start dates. That way all of the 30, 60, 90, and annual review notices would go out together once a week, the workflow is protected from staff reorganizations, software updates and server changes, and the license only requires one workflow.


While this is an extreme (and real) case, take a look at your own workflows to see if they would run better sideways to the business process or in smaller sections. The key is to separate the overall business process (in this case regular employee reviews) from the task that is being automated (identifying upcoming review dates). Rather than modeling the Business process in your workflow, it may be better to run a regularly scheduled workflow, or wait for something to happen and use that event to trigger your workflow?


The decision is yours.