Workflow operations are batched – meaning they don't necessarily commit their changes when you think they do, most of the time. All of the default SharePoint activities participate in this batch, none of the following do:
- The Code activity
- Non-SharePoint activities (i.e those that ship with Workflow Foundation)
- Our custom activities
When the out of the box activities execute, any changes they make to elements from the SharePoint Content DB are added to a batch that is not committed until the workflow persists. (To understand when this happens, see here: Workflow Processing Overview ) For our purposes, this means that the following workflow will have issues (assuming the Code activity attempts to access the newly created Task):
This is because the Code activity (CheckTaskTitle ) does not participate in the batch while the CreateTask activity does. Therefore, the task is not actually created when the Code activity attempts to manipulate it. In order to make this work, you need to change your workflow slightly:
The onTaskCreated activity causes the workflow to persist, which causes the batch to commit so that when the Code activity (CheckTaskTitle) executes, that Task has actually been created.
The other very important aspect to this is that if you need to rollback manually in a fault or cancellation handler, you need to pay particular attention to what has/has not been committed. Also, if the batch itself rolls back, activities that are not in the batch will not be rolled back.
This is a pretty simplistic scenario, but it makes the point pretty handily.