When working with Workflow it is possible to add a waitfor activity to build some sort of Escalation mechanism. Very interesting, and often used I would say. But when using Workflow Foundation you must be reminded that Workflow instances will only run when the Worflow Runtime is running.

This is very interesting in standard ASP.NET scenario's. Most of the time you will choose to host your Workflow runtime in one of the ASP.NET processes. At first this doesn't sound like a problem. But have you ever noticed your ASP.NET processes are recycled after some inactive time? This won't happend on a ASP.NET application with heavy traffic, for every minute in a 24-hour day. But a lot of companies have ASP.NET Intranet applications, which are active for some time during the day, and inactive during the night.

When hosting your Workflow Runtime in your ASP.NET process this will make sure your Workflow Runtime will be recycled during the night. So there must be a mechnism to make sure your Workflow Runtime doesn't stop. Because a stopped Workflow Runtime means no running Workflow instances. You can use a Windows Service to leverage a Workflow Runtime, but communication with a Windows Service from inside your ASP.NET application isn't that simple. But we are allowed to make a choice for this, what would we want.

But how does this work in Sharepoint 2007?

I couldn't find an answer to this. At least not directly. I found an article about how to debug your Workflow instance that is hosted by the Sharepoint Workflow Runtime. This article explains how you can debug your Workflows inside Sharepoint. You are instructed to attach your debugger to the w3wp processes, the standard processes in which ASP.NET operates. This asumes to me that the problem described also exists in Sharepoint. But can anyone assure that the Workflow runtime is hosted on the w3wp process?