This week I was working with a client on bringing their Safety Manual process into SharePoint; utilizing some SP Designer approval workflows and Word Automation services. This was going to help improve their processes and bottlenecks associated with updating the manual and proving the most recent, accurate copies to the users within the organization. Everything was moving along smoothly once we got the MMS issues straightened out and we were 99% done with the project. The last step was to set the workflow updating the metadata on the PDF to run automatically once the PDF was added to the document library. Here’s where the fun began.
Once the PDF document was created and added to the document library, I had expected my SPD workflow to execute and copy the metadata fields from the word document, to the pdf document with the same name. Unfortunately, what was happening was that my workflow attempted to execute and then the operation would fail. “Failed on Start”
After much research, I discovered that SharePoint Designer workflows will not successfully execute on the programatic addition of a document to a library via Word Automation Services. It will run fine if a user uploads a document, but not when programmatically adding the doc. In more detail, SharePoint Designer uses a declarative rules-based code free workflow. After the addition of SP1 back in MOSS 2007, the System Account is no longer allowed to trigger declarative workflows and this security feature stands true in 2010 as well. Since it appears to be the system account that adds the PDF via Word Automation Services, it makes sense that the workflow will not execute properly after the document is added to the library. I should note, that it didn’t seem to matter that the PDF does not show the “Created by” as the System Account, nor does the Word Automation Service or its associated Application Pool run under the system account; so it does not appear to be something that can be worked around by updating an account somewhere.
The other factor may be the way that the code is compiled. A declarative workflow is compiled in the content database each time an instance of the workflow is started, whereas a code workflow is stored on a server and precompiled. The timing of the compilation may also conflict with the timing of the addition of the document to the library. I haven’t received confirmation as to which of these issues was the determining factor to the SPD workflow failure but either (or both?) could be contributing factors.
The good news is, after rebuilding the workflow in Visual Studio, the workflow updated the metadata on the pdf document, as expected after the addition of the document to the library. Its always good to keep in mind that SP Designer does have its limitations and it may be worth some research (ahem….planning!) to make sure you can successfully execute your plan without code.
**************************************************
Side note, I had downloaded this solution from CodePlex, that allowed me to utilize Word Automation Services within SharePoint Designer so I didn’t have to code my own solution. It works great! This solution adds custom actions to SPD so that you can convert a document within your SPD workflow. I had also rebuilt this process in Visual Studio in case it had something to do with the way the document was added to the library, but it was unrelated and the problem remained even when Word Automation was triggered by a Visual Studio workflow. So – for those of you non-coder/Admins out there, this is a great solution.
