Let me explain by way of an example. You have implemented a custom insitu EDRMS solution which will set the permissions on an item to ‘Readonly’ when the item’s Item Status column is set to a value of ‘RECORD’. In making the item a record there are other functions to perform such as recording the event in an EDRMS register. Due to the length of time this process will take you may decide to implement a workflow to start when the item is updated.
The fly in the ointment, is the library that contains the documents may have forced checkout set. When an item is in the checked out state all workflows are blocked. The user has to check the item out so that the item status can be set to ‘RECORD’. The item is then saved by the user who then forgets to check the item in. The workflow does not start and the EDRMS function is incomplete.
AN ASIDE: The blocking of the workflow also has implications when trying to debug the workflow in Visual Studio's IDE. You may see the breakpoint you have set displaying a warning symbol and the message "The breakpoint will not currently be hit". The item that the workflow is associated with displays a status of 'Starting'. As soon as the item is checked in the workflow will start and your breakpoint will be hit.
So in this situation the only choice you have is to use the asynchronous ItemUpdated and ItemAdded event receivers in conjunction with the workflow. The event receivers can be used to check the item in when the item status is set to ‘RECORD’. This should be the only task the receivers perform as we want the overhead of firing the events to be minimal. Having checked the item in, the workflow will proceed.