Infinite Loop Detection

This may be another candidate for the "if I had a penny..." series. It's not a new item but I've come across it enough times that I thought I'd bring attention to it.

Microsoft implemented an "infinite loop detection" mechanism within the workflow process. For example, it's possible for you to design "Workflow 1" that calls "Workflow 2" and then "Workflow 2" calls "Workflow 1" again, such that the workflow - once initiated will theoretically never end. And if these workflows are designed to call each other within moments of being initiated, things could potentially spiral out of control. And it is presumably for this scenario that Microsoft implemented it's "Infinite Loop Detection" mechanism.

You will have encountered this error when you open up a failed workflow and find the "workflow job was canceled because the workflow that started it included an infinite loop" message.

According to literature I've read on this topic, this error only occurs when  "a workflow calls itself (on the same entity) more than 7 times in an hour, the 8th instance will fail with the error..."

While in principle this may be a good mechanism, there are times when it gets in the way of good design. In fact, it can be argued that Microsoft puts such mechanisms into place as the lowest common denominator. Meaning that as Microsoft CRM is essentially a product that is designed for the masses and therefore there is no guarantee that those who "configure" CRM will be responsible enough to make wise decisions. In fact, CRM greatest strength could also - in the wrong hands - be its greatest weakness. That is, the application is so easy to customize/configure that you certainly do not have to be highly trained or technically qualified consultant in order to configure the system. But in the inimitable words of Spiderman: "with great power comes great responsibility". And therein lies the risk because when it comes to system design it is the THINKING - both short and long term - that is paramount. And therefore beyond the capability of being able to perform configuration/customizations on the system it is crucial to know when to add a new attributes, vs. entity, vs. relationship etc. etc. This topic clearly requires further development - perhaps for another time - but I digress, time to reel it in...

The point is that Microsoft - who knows that the product will equally be at the mercy of both the talented and not so talented (when it comes to technology) and that it's impossible to control who will have the keys to the kingdom at any given moment - has put in controls to protect the people from themselves. And this is but one example (another much better example is Microsoft's strict policy of not allowing direct updates to the CRM database - definitely a topic for another time).

Back to the issue at hand - it is perfectly good design to have multiple workflows calling each other. In fact, it could even be a recommended due to the modularity of such a design approach. But yet, if you do so you may hit up against this issue even though your human decision making skills are better than that of a computer in terms of detecting infinite loops - at least in this case.

And the "penny moment" here is - why didn't Microsoft recognize this might happen and give the end user the ability to override the behavior either through a global setting or through a specific workflow setting? Maybe this has been implemented in a different way in CRM 2011 - I haven't had a chance to check. Anyone?

In this case, the absence of such a setting is not that critical as I think the likelihood is that encountering this error is likely to be the result of testing rather than something that would occur in the real world. Because in the real world it is probably unlikely that you'd want to process more than 7 workflow steps in an hour. At least in theory, but even encountering this error in a test environment can be a pain.

Although there apparently is no setting to override this behavior, there is an ability to increase the threshold from 8 as described in this article. I am not sure if there is an upper limit - I remember at one point trying to increase it but still being dogged by the issue at an upper limit. If there's no upper limit, then indeed setting this threshold to a very high number would give a way to override this setting in which case I don't get my penny...