You are of course aware of the fact that starting with Service Pack 1 the workflows created in SharePoint designer that should launch under the credentials of the system account will no longer start automatically.
You know what the resolution is for this problem: simply do not to use the system account.
You implemented all the steps written here http://support.microsoft.com/kb/947284 ,but the workflow still does not start.
More interesting, if you email-enable a document library and attach a workflow to it, and set the workflow to start on Item creation, this workflow will never start.
This usually happens because the e-mail is saved into the document library using the sharepoint services timer service account credentials. If an e-mail was created by the system account then the workflow will attempt to start using the system account which is no longer permitted.
As you cannot change the credentials for the for the timer service, what should you do?
The answer is pretty simple: install Infrastructure Update http://support.microsoft.com/kb/953749/(and of course if you are at it, you can update the whole farm to the latest patch level (FEB CU) ) and pay close attention to one small line (made bigger here because of it’s importance) written in the notes part of the knowledgebase article:
To prevent the declarative workflows from impersonating the system account, the workflows will now impersonate the user who created the workflow association.
This basically means that you should create a special account not SHAREPOINT\SYSTEM, that is a site collection owner on the site collection where the workflow is hosted, open the workflow in SharePoint Designer while logged on as this new account and simply save the workflow without modifying anything.
It will effectively change the account that associated the workflow, which will allow it to start.
you should also run
stsadm -o setproperty -pn declarativeworkflowautostartonemailenabled -pv true
to enable workflows to start using the impersonation scheme