Firing a SharePoint Workflow by updating a list item through List Webservice - MS verified bug, solved

Question

I am developing, a simple SharePoint Sequential Workflow which should be bound to a document library. When associating the little workflow to a document library, I checked these options

• Allow this workflow to be manually started by an authenticated user with Edit Items Permissions.
• Start this workflow when a new item is created.
• Start this workflow when an item is changed.

Now I upload a document to this library and the workflow starts and for instance sends a mail. It completes and everything is fine.

When I select Edit Properties on the new Item and save a change, the workflow is fired again. Absolutely what we expected.

Even when copying a new Item into the library with help of the Copy.asmx Webservice, the workflow starts normally.

But now I want to update the item via the SharePoint WebService Lists.asmx.

My CAML goes here:

<Method ID='1' Cmd='Update'>
  <Field Name='ID'>1</Field>
  <Field Name='myDummyPropertyField'>NewValue</Field>
</Method>

The Item is being updated (timestamp changed and a dummy property, too) but the workflow does NOT start again.

This behaviour is reproducable on our development and test system.

Checking the error logs (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS) I discovered a strange error message:

09/25/2008 16:51:40.17  w3wp.exe (0x1D94)                        0x1D60 Windows SharePoint Services    General                        6875 Critical Error loading and running event receiver Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver in Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c. Additional information is below.  : The object specified does not belong to a list.

Anybody who can confirm this behaviour? Or any solution hints? This would be great!

I am keeping you informed of any developments on this topic.

Answer 1

I've encountered this issue as well and found out that once a workflow has started, it cannot be re-started automatically, no matter how you update the item. You can, however, manually start the workflow again, as many times as you like.

Answer 2

We faced a similar issue with an Approval Workflow. To solve it, we wrote our own Event Receiver and attached it to the list. Depending on whether the item was updated or edited, we then fired the Approval Workflow.

Hope this helps...

Answer 3

We are still in contact with Microsoft about this issue. The ticket is now lifted up to the next support level, where Microsoft staff can take a look into the source code of the List.asmx Webservice.

As this might take a longer timeframe, I tried the workaround from our unknown friend above. It works as described and solved our problem, until MS fix it. Thanks!

If anybody needs more information about the custom event handler, let me know.

Answer 4

I have seen the same behavior. But then you get posts like this showing people how to create one per day to set up email reminders…

http://sharepointmagazine.net/technical/development/the-dog-ate-my-task-use-sharepoint-designer-to-email-daily-task-reminders?disqus_reply=3886089#dsq-alerts

Answer 5

Finally, we got through the support services processes at Microsoft and got a solution!

First, Microsoft stated this to be a bug. It is a minor bug, because there is a good workaround, so it may take some longer time, until this bug will be fixed (the support technician said something with next service pack oder next version (!)).

But now for the problem.

The reaseon

Let's take a look at the CAML code from my question:

<Method ID='1' Cmd='Update'>
  <Field Name='ID'>1</Field>
  <Field Name='myDummyPropertyField'>NewValue</Field>
</Method>

For any reason the Workflow Manager does not work with the ID, we entered in the second line. Strange, all other SharePoint commands are working with the ID, but not the Workflow Manager. The Workflow Manager works with the "fully qualified" document name. So, because we had no clue and didn't entered any fully qualified document name, the Workflow Manager defaults to the name of the current document library. And now the error message begins to make sense:

The object specified does not belong to a list.

Of course, the object (document library) does not belong to a list, it IS the list.

The solution

We have to add one more line to our CAML Query:

<Field Name='FileRef'>/sites/mySite/myDocLib/myFolder/myDocument.txt</Field>

The FileRef passes the fully qualified document name to the Workflow Manager, which - now totally happy - starts the workflow of the item.

Be careful, you have to include the full absolute server path, omitting your server name (found for example in ServerRelativePath property of your SPItem).

Full working CAML Query:

 <Method ID='1' Cmd='Update'>
    <Field Name='ID'>1</Field>
    <Field Name='FileRef'>/sites/mySite/myDocLib/myFolder/myDocument.txt</Field>
    <Field Name='myDummyPropertyField'>NewValue</Field>
  </Method>

The future

Perhaps this undocumented behaviour will be fixed in one of the upcoming service packs, perhaps not. Microsoft Support apologized and is going to release an MSDN Article on this topic. For the next month I hope this article on stackoverflow will help developers in the same situation.

Thanks for reading!

Answer 6

I have the same error, no solution worked for me, so I decided to use this workaround: http://www.dailycode.net/blog/post/Error-in-SPWorkflowAutostartEventReceiver.aspx