I’ve had a couple of questions about this in the last few months so I wanted to provide some information on what’s happening with Workflow 3.5 and what’s this silly limit for the maximum complexity – and worse yet, how did I hit it?

So making a long story short, Workflow 3.5 compiles the XOML that SharePoint Designer generates into a DLL. When that DLL is called there’s a method that creates the workflow object graph. When it’s doing this it pushes a bunch of “stuff” on to the stack. If it pushes too much on the stack we get a stack overflow. How much of the “stuff” does it take? It depends. However, at 10,000 items it gets tight. If we get a stack overflow it dumps the thread and aborts – which is, of course, a bad thing. So SharePoint put a limit in for the maximum number of items that can be in a workflow for SharePoint to ask for it to be compiled. That number is 7,000 by default but can be adjusted. (Caveat emptor)

So what is this “stuff” of which I speak? Well according to a good source, it’s activities, bindings, variables, and rule-references. Note I said activities, not actions. If you’ve seen one of my workflow presentations you’re used to me creating a simple workflow with just an approval action and then importing it into Visual Studio to find 315 activities. All total, there’s roughly 1,000 activities, bindings, variables, and rule-references in a single “approval” action in SharePoint Designer. So clearly if you did eight different “approvals” in a single workflow you’d exceed the default limit. This also applies for custom task processes.

I’m assured that you can get multiple approvals to work inside of a single “approval” activity – but it’s not as easy as plunking down another activity task – so it’s not impossible to do eight-level approvals with SharePoint Designer, it’s just that it gets more challenging.

If you do “need” to change the value of UserDefinedWorkflowMaximumComplexity – it’s a property on the web application. (Have I encouraged you not to do it yet?)