В оригинале эти особенности описаны в блоге группы BCS:
Workflows cannot be associated with an External List
In SharePoint 2010, workflows cannot be associated directly with external lists. This is because the data is not stored in SharePoint, so the workflow cannot be notified when items change. This does not mean that workflow does not work with external lists. You can create a site workflow, or just have a list workflow on a regular list, like a document library, and have it read or update from an external list. You can also use an external list item as a destination for a task process in SPD, although the link to the task will always show no title for the external list item.
Workflows accessing BCS will always run as service account, even under impersonation step
Workflow will always run as a service account (typically the IIS Application Pool account) and is only supported when using Secure Store Service (SSS) or RevertToSelf (which is turned off by default due to security implications). This limitation is designed to protect SharePoint from malicious models/developers. Because access to the backend will always be initiated as one account, you will lose track of who is making the changes. To work around this, you can have the workflow pass the SPUser name to a column on the external list or to a custom activity that uses the BDC APIs, but this would be more for informational purposes and shouldn’t be used as an iron-clad security feature.
Источник:
Коротко так:
Во-первых, рабочие процессы не могут быть ассоциированы с внешними списками. Т.е. запускать процесс по событию создания или изменения элемента внешнего списка не получится.
Во-вторых, рабочий процесс работает с внешними источниками только с использованием либо Secure Store Service либо RevertToSelf. При этом рабочий процесс обращается к SSS под сервисной учетной записи (как правило, под учетной записью пула приложений).
Сейчас готовлю видео, в котором в том числе демонстрируется использование внешнего списка в рабочем процессе.
