I am experiencing difficulty creating a file in a document library using the client object model. My custom Visual Studio 2010 workflow is not detecting the updates I am making to the file's list item after it is created.

I'd like to give an idea of the infrastructure to answer some likely questions:

  • The document is uploaded to a web service, which is responsible for actually inserting the document in the library and configuring the values of its list columns
  • The web service is performing this operation using the Client Object Model
  • The web service is authenticating against the SharePoint site with an account created for business intelligence automation that DOES NOT RUN as the system account when interacting with SharePoint; it is, however, a member of SharePoint owners
  • The operations in the custom workflow depend on the file's list item columns being populated before it can proceed to assign tasks to the users in two of those columns; for that reason, I created a While activity to monitor changes in the list item until those two columns are no longer null

The following is a sample of what the web service is doing. It is running in IIS under the Business Intelligence user identity. I've added some comments as to which operations I was anticipating the workflow would respond appropriately.

Using client As New ClientContext(My.Settings.SharePointSiteURL)

    // Pre-processing to determine appropriate user ID values for columns

    Dim fci As New FileCreationInformation() With {
        .Content = IO.File.ReadAllBytes(storagePath),
        .Overwrite = True,
        .Url = String.Format("{0}/{1}", theList.RootFolder.ServerRelativeUrl, theFileName)

    Dim theFile As Microsoft.SharePoint.Client.File = theList.RootFolder.Files.Add(fci)

    // Expecting the workflow to be activated here

    theFile.ListItemAllFields("Project_x0020_Manager") = pmId
    theFile.ListItemAllFields("Project_x0020_Accountant") = paId

    // Expecting the onWorkflowItemChanged activity to be invoked here
End Using

The workflow does activate when a file is uploaded and continues on to wait for a change event from SharePoint, but that event never arrives as a direct result of the web service's operations. I'm able to modify the item manually and successfully continue on.

Is there a consideration when using the Client Object Model that might preclude these events from firing normally?


3 Answers 3


I'm having similar issue here. Almost exactly the same scenario. As far as it seems the upload of the file and update is happening too close together. I've tried updating an item after a while and the workflow continued with OnWorakflowItemChanged event.

Perhaps you could try with Thread.Sleep(1000) or a bit more time before second update - just for experimenting?

  • I got similar sentiments from a reply on StackOverflow. This may be a bug in the process model for SharePoint workflows that results in a race condition in detecting the first change event. I've elected to move my code inside the workflow proper. I don't like the solution, but trying to wait out a race condition is too non-deterministic for my tastes. It does appear, however, that a thread sleep could have some efficacy in resolving the problem. Commented Nov 20, 2012 at 21:45
  • Could you explain how do you plan to move your code into worklfow? Do you have a workaround for "waiting for data"?
    – Gomiunik
    Commented Nov 20, 2012 at 22:45
  • 1
    In my case I was able to parse the name I gave the file in my web service to get the bare minimum data I needed and used it to retrieve the rest from a database. It was a contrived solution but it worked around the problem I was having. There was only so much intellectual ping-pong I had time to play with because of looming deadlines. Commented Nov 21, 2012 at 14:12

After a lot of painstaking research and experiments, endless uploads to document library and deletes, at the end what did the trick for me is as follows:

I have the OnWorkflowItemChanged event in a loop - the same as you have.

I've added a method on invoked and changed the WaitForIdle to true in the event args

private void OnWorkflowItemChanged(object sender, ExternalDataEventArgs e)
    e.WaitForIdle = true;
  • This is interesting. I'll be sure to check it out. Commented Nov 21, 2012 at 14:10
  • I'm afraid this approach didn't prove at all fruitful in any of my testing. Commented Nov 21, 2012 at 14:54

Another thing that worked for me (and was even better than holding up threads) was to put after the line

Dim theFile As Microsoft.SharePoint.Client.File = theList.RootFolder.Files.Add(fci)

the following:


and after


the following:

theFile.CheckIn("", CheckinType.MajorCheckIn)

The checkout and checkin somehow got the workflowstarted event a head start before the onworkflowitemchanged, I gues.. The best would be that MS would fix this issue in a hotfix, so events wouldn't get ahead of themselves.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.