Struggling with "Wait for Linked Request Update"

[samwoo]

God afternoon,

Two BPM's running parallel, one for the Release ticket and one for the child SR tickets for that Release. Everything is working seamlessly together until within the SR ticket, I get to the node "Wait for Linked Request Update".

 

I can confirm that the SR ticket(s) has reached the above node, way before the completion of the Task on the Release ticket that populates the Release Timeline with "Build Release" but the node in the SR ticket is not capturing the timeline update form the Linked Release.

The Release node timelines actually populates with this:

But no matter what I put in the "Contains" field within the SR's "Wait for Linked Request Update" node, it doesn't trigger to take the SR out of suspend state.

Please can you advise what I am doing wrong, or whether this is a defect?

 

Here is the BPM for the SR. The highlighted node relates to the first screenshot above: (ignore the warning icon, I have a calculation going on which works perfect)

 

Here is the BPM for the Release:

Here is the "Update Timeline" node for the Release BPM:

 

Thanks,

Samuel

[James Ainsworth]

Hi Samuel,

Is this update automatically generated from the workflow or is it a manual update from the Update Action?  Can you test by adding a manual update in the linked request that contains this information? I seem to recall that this suspend task is listening to the Update Action and not automated updates. 

[samwoo]

HI @James Ainsworth,

Thanks for that, it works when I type it into the timeline manually. I think the information on the Wait for Linked Request Update node is misleading:
 

 

It should reflect that it only works for manual updates to the timeline and not via the BPM.

But now that begs the questions, how can I trigger the next stage of the Service Request child ticket(s) based on an "Automated" update to the parent Release ticket?

Please can someone advise, as I am going live with this Release process next week.

Thanks,

Samuel

[samwoo]

Looks like this was an issue back in 2018 and was then later fixed, and now an issue again?

 

[Steve Giller]

The fix that is referenced in the Thread above states:

Quote

When a linked request BPM is suspended at the Wait for Update node, and the parent request BPM applies a timeline update to linked requests, the linked request BPM doesn't resume and stays suspended at the the Wait for Update node

This is not the issue you are experiencing, it is referring to when the Linked (Child) Request has a Suspend->Wait for Update node and the Parent Request pushes a Timeline Update to the Child.

This does not relate to the Suspend->Wait for Linked Request Update which is, as @James Ainsworth describes above, only triggered on a manual update.

[samwoo]

Ah thanks @Steve Giller, a bit under pressure to get this all working, so got confused.

So from what I can understand there is no way to take a BPM out of suspension when a linked request has been updated via it's own BPM? If that's the case, then are there any other workarounds where I can get this working?

All I need is one (or all) of these

• Suspend the Service Request BPM, and when a linked Release timeline is updated via the Release BPM, move the Service Request BPM on
• Suspend the Service Request BPM, and when the Service Request timeline has been updated via the Release BPM (using a new Update Linked Request Timeline node?) with specific text, move the Service Request BPM on
• Suspend the Service Request BPM, and when a Custom Field has been updated on any linked Release request with a specific value (using a new Suspend - Wait for Linked Request Custom Field Value(s) ), move the Service Request bpm on

Thanks,

Samuel

[Steve Giller]

Parent Request:

Request Id value is: &[global["flowcoderefs"]["logRequestIncident"]["newRequestId"]]

Child Request:

Request Id value is: &[global["flowcoderefs"]["getUpdatedReqInformation"]["externalRefNumber"]]

This gives (on the Parent):

and the Parent workflow moves on - in my case to close the test off.

 

[samwoo]

Thanks @Steve Giller.

 

I have already done this much earlier on in the child request process. I am at the stage where I have run out of things to suspend and wait for against the parent ticket, but there are 3 more stages of the Release to go through and the child tickets will need to wait for things to happen at each of these stages. (Next stages are triggered by the completion of Human Tasks in the Parent ticket).

 

I've got no choice but to request for an enhancement for these (they can be used in conjunction with each other):

• Enhance "Wait for Linked Request Update" to also work for Linked Requests updated via BPM and not just manual update. Add further conditions, such as Service, Catalog etc.
  Use case:
  • Suspending a Child BPM, and when a linked Parent timeline is updated via the Parent BPM, move the Child BPM on, and vice versa.
     
• Enhance "Wait for Timeline Update" to include a "Contains" field so we can test for a value.
  Use case:
  • Suspending a BPM and wait for the timeline to be updated with containing text
     
• Add "Wait for Linked Request - Custom Field update".  Add further conditions, such as Request Type, Service, Catalog etc.
  Use case:
  • Suspending a Child BPM, when any of the Parent BPM's Custom Field has been updated (manually or via BPM) then resume the Child BPM.
     
• Add "Update Linked Requests - Custom Fields".
  Use case:
  • Update all Linked Requests - set a value for the specified Custom Field for all Linked Requests. Add further conditions, such as Request Type, Service, Catalog etc.
     
• Add "Suspend and wait for Custom Field value". Add Expiry, Notice and Manual Timeline Update capabilities.
  Use case:
  • Suspends the request and waits for a specific value in the specified custom field.

 

I am struggling to have a think about what to do in the meantime. The weekend will probably help!

Thanks,

Samuel

[Steve Giller]

13 minutes ago, samwoo said:

I am at the stage where I have run out of things to suspend and wait for against the parent ticket

Unfortunately I have no idea what that means.

Possibly because there is technically no Parent or Child ticket, they are just linked Tickets. Thinking about them as parent and child is useful for the external process, but makes no real sense with regards to the Workflow itself.

However for "Requests waiting for other Requests":
Suspending a "Child" BPM, and when a linked "Parent" timeline is updated via the "Parent" BPM, move the "Child" BPM on, and vice versa.
becomes
Suspend a "Child" BPM, and when a linked "Parent" timeline is updated via the "Parent" BPM, also post an update to the "Child" BPM - a "Wait for Request Update node will then move the "Child" BPM on. (and vice versa is irrelevant here, the "Child" BPM is simply the one that is waiting.)
 

[samwoo]

On 9/8/2023 at 5:17 PM, Steve Giller said:

Unfortunately I have no idea what that means.

 

Hi @Steve Giller,

The child "Service Request" tickets are dependent on the stages in the parent "Release" ticket. 

At each stage/checkpoint of the "Release" ticket, I expect the child "Service Request" tickets to suspend and wait for something to happen to the "Release" before they move on to their next steps.

When the tasks for the child "Service Request" tickets are completed, the information is automatically populated into the "Release" ticket timeline and put into suspension until a certain point in the "Release" ticket is reached.

Once the "Release" owner is satisfied that the child "Service Requests" have completed their necessary steps, then they will complete the Human Task and then the child tickets will then move onto the next steps accordingly.

This is why I was hoping to use "Suspend -> Wait for Linked Request Update" in the child "Service Request" tickets where the timeline update contains specific words. But as I have found out, "Wait for Linked Request Update" only triggers on manual timeline update. I need this to work on BPM timeline updates as well hence my first enhancement request above.

Failing that, I then need a way to suspend the child "Service Requests" and wait for updates somewhere else in the "Release" ticket, for example on Custom Field change.

I'm probably still not making any sense...

[Steve Giller]

2 minutes ago, samwoo said:

Failing that, I then need a way to suspend the child "Service Requests" and wait for updates somewhere else in the "Release" ticket, for example on Custom Field change.

At present the only option is when the triggering update happens in the "Release" ticket you post an update to the relevant "Service Request" ticket's Timeline - this will be able to move the SR on if it's waiting at a Suspend->Wait for Request Update node, you just need to ensure that it's not an update from another source. For that you might also need to update a Custom Field in the SR (from the Release BPM) and test that value before moving the SR along.

[samwoo]

Thanks @Steve Giller - that's an idea - thank you i'll have a little play with that. In fact, I wonder if a loop checks on Wait for Request Update to check for a specific value using a decision node might be an idea... 

SR BPM:

1. Wait for Linked Request Update
2. Get Request Details (of Release)
3. Decision
   • IF custom field value == "Build Release" then go to 4
   • else go back to 1
4. Human Task for "Build Release"

 

Would that be too much for the BPM?

Thanks,

Samuel

[Steve Giller]

Loops have to be used with caution and tested on a case-by-case basis - the main potential issue I see above is it's still using Wait for Linked Request Update which relies on a manual Timeline update.

[samwoo]

thanks @Steve Giller, i'll have a go and see what can be achieved.

In the meantime, is it possible for you to tag this post as "Enhancement" or would you prefer that I create a new topic for the developers?

[Steve Giller]

I'm holding back on that until Development confirm this is expected behaviour, just in case.

 

[samwoo]

Thank you @Steve Giller that makes sense

[samwoo]

Hi @Steve Giller,

Just to let you know that I've not had any luck with waiting for the linked parent "Release" to update via the child "SR"s.

The "Wait for Linked Request Update" node definitely needs to also wait for updates made via BPM (could be a toggleable option?) - but I will wait for you to confirm via the developers whether this is a defect or by design.

Unfortunately, I am, at this point, unable proceed with further automating this, so will check if the service team are happy to do it all manually until (hopefully) these feature requests I made above are introduced and/or fixed.

Thanks,

Samuel

[Steve Giller]

It's now been confirmed that this is expected behaviour, Update in this context is the Update Action.

[samwoo]

Thanks @Steve Giller.

Here is my first enhancement request:

 

[samwoo]

Here is a linkback to the other enhancement request I have raised: