0

I have a fairly complicated script written using the JSOM in Javascript that synchronizes two lists based on user behavior. At one point a user interacts with a SharePoint form that, on closing, triggers a workflow to initiate. After the workflow has been triggered, the script updates a series of fields and should go on its merry way.

However, this is not happening. Instead, whilst I am able to get the item the workflow is operating upon, the moment I call the query to update it, everything hangs until the workflow completes, at which point the JSOM finishes executing asynchronously and does its thing. This would be fine, except I need the changes to be there when the workflow looks for them - that's why it is pausing in the first place.

Does anyone have any ideas off hand as to how to prevent the workflow and script from getting in each other's way?

Improve this question
6
  • Is the workflow being triggered via JSOM as well?
    – wjervis
    Commented Mar 7, 2017 at 17:34
  • Also, I edited your question since CSOM usually refers to C#. Client object model in JavaScript is referred to as JSOM.
    – wjervis
    Commented Mar 7, 2017 at 17:36
  • Not yet, although it's one of the mitigations I'm looking into. Can't actually remember how to launch a workflow via JS, although I can think of a couple of ways to early exit unless JS has caused certain conditions to be met.
    – tobriand
    Commented Mar 7, 2017 at 17:39
  • 1
    Perhaps add a field to the list that you update via JSOM, and then have the workflow wait until field equals the value you set it to. Otherwise, do it all via JSOM.
    – wjervis
    Commented Mar 7, 2017 at 19:32
  • Eventual solution (at least for now) was to roll back to a 2010 workflow which doesn't cause blocking. I tried adding in the extra field, which looked promising but didn't behave as expected, and eventually just decided the fastest resolution would be to use old technology.
    – tobriand
    Commented Mar 8, 2017 at 12:36

1 Answer 1

Reset to default
0

There are two obvious ways to address this:

  • A tracking field to say when the workflow is ready
  • Rolling back to a SharePoint 2010 workflow which definitely does not do blocking.

The first of these should be the solution. That is, create a field in the list called "WorkflowReady", which JavaScript sets to true once the workflow CAN operate on the field, and the workflow then early exits unless it's true. Assuming blocking operates as expected, this is fine.

However, when I tried it, I found it difficult to confirm that the list item is ALWAYS blocked by either JS or the WorkFlow, leading to the possibility that the worflow starts, check's the value of the field, and yields to JavaScript before finishing. JavaScript could then set the ready field to True BEFORE the workflow completes, the workflow then completes, and the row just sits there, ready to be started but not triggered because the changes were effected during its previous execution. I did not observe this behaviour, but since I couldn't confirm that it would never take place, I didn't go down this route.

The other approach, however, of rolling the workflows back to a 2010 paradigm did the trick. It's far from ideal - sooner or later I guess MS will retire 2010 workflows - but for the immediate problem, it did the job.

Improve this answer

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.