Some recent threads lead me to read this information about handling workflow interruptions: http://msdn.microsoft.com/en-us/library/af226209-cfef-4aeb-86db-e859642459d0#BKMK_HandlingWorkflowInterruptions It contains an interesting statement I would like to explore in more depth: You should design a workflow so that it can be restarted if it does not finish (for example, if the server goes down during processing). In this case, a new instance of the workflow is created that does not have access to the original Request object that caused the workflow to be run. This raises some interesting questions: 1 - Why doesn't the workflow have access to the original Request object that caused the workflow to be run? 2 - What does this mean for all of the workflows (and workflow activities) out there that are based on the CurrentRequest activity? 3 - I would like to "design a workflow so that it can be restarted if it does not finish." Unfortunately, the article does not explain how to do that in the case above where the original Request object cannot be accessed. Can someone explain how a workflow that relies on the CurrentRequest activity can be designed so that it can be restarted? -Jeremy

Hi Jeremy, >Why doesn't the workflow have access to the original Request object that caused the workflow to be run? If you don't have a dependency in the action workflow on the triggering request, then in the event of some wide scale workflow failures (due to service interruption/crash, or other issue), you can simply re-run the workflows using the "run on policy update" feature. However, when you re-run workflows using the "run on policy update" feature by simply creating a new transition-based MPR whose target set contains the resources you want to run the workflow on, the request that triggers all those workflows is a request to create an MPR, which is almost certainly different than the request that triggered the originally failed version. Having a dependency on the triggering requets removes this recovery option for you. >What does this mean for all of the workflows (and workflow activities) out there that are based on the CurrentRequest activity? This really only applies to action workflows, since if an authZ or authN workflow fails, you cannot restart it as the associated request would also fail due to the dependency on all authZ and authN workflows passing. You would need to re-submit "denied" requests that resulted from a failed authN or authZ workflow. For action workflows that are based on the CurrentRequest activity, this best practice implies that those action workflows should be revisited, if the ability to re-run them is important, in order to assess how they can be refactored to not rely on information that is specific to a certain type of request. >Can someone explain how a workflow that relies on the CurrentRequest activity can be designed so that it can be restarted? Again, this only applies to action workflows (authZ and authN by nature will likely have some dependencies on the triggering request, as they are validating something about it). How to refactor a given workflow to not be dependent on the triggering request would need to be assessed on a case-by-case basis, as it depends on what the requirements of the workflow are.