Enhancement: Passing Custom Fields across in Log New Service Request node

[Berto2002]

I would like to be able to pass-across Custom Field values from the parent Request to the newly created Request when I use the Hornbill Automation node Log Request.

Use case: our New Starter process 'spawns' a couple of other Requests: one for mobiles and one for applications. Some of the information collected in the New Starter PCF needs to get into those other Requests. An example is that we have a specific set of approvers in the New Starter PCF for Mobile phones which store as Custom Field B. If I cannot pass that value over to the Hardware Request, I have no way of using that information in the new Request. This means I need to duplicate a decision and Authorisation step in the New Starter Request that I only really want to have in the Hardware Request.

Is there a way of passing such information from one Request to another through workflow?

[Steven Boardman]

@Berto2002 you should be able to achieve this now.

In your log Request node, one of the output params is the id of the new request:

If you follow this node with an update custom fields node in the workflow on the primary ticket

In the Request ID input field which is normally left at Auto set this to Variable and use the variable picker and inject the requestid output param from the Log New request node. - this will then allow you to update the custom fields on the new ticket from the existing ticket.

In the custom fields, you can use the variable picker to inject the values from the existing ticket using a Get Request Info > Request Details node before the update custom fields node.

Hope that makes sense

 

[Berto2002]

Genius! Very timely. I'm going to try this now!

[Berto2002]

@Steven Boardman, This worked, thanks for the suggestion.

However, I hit a snag in that the first node created the new Request which then went on its merry way through it's workflow before the second node on the original workflow had had a chance to update some fields with values that workflow uses.

I have worked-around this by introducing a wait for... node with an expiry of 1 minute and a Notice that says, "Please wait 1 minute for all the information to be copied over from the New Starter Request". This is more than adequate (by about 59.5 seconds!) for that update to occur.

I could also have tried to re-engineer my workflow so the critical step occurred after an existing natural pause but that would have been much work in this case.

Just highlighting where updates through a second node are potentially more problematic than allowing the original request creation node to carry-over all the fields present in the Update request nodes.

[Victor]

1 hour ago, Berto2002 said:

I have worked-around this by introducing a wait for... node with an expiry of 1 minute

For the time being, I am strongly advising against using the Await For Expiry node, especially with a 1 minute timer. We have a problem record on our list as we know this node can intermittently fail to resume the workflow after the minute passes. So 1 minute in Await Expiry node is not currently reliable... It is even more problematic when it eventually comes to fixing a running workflow that did not resume as configured... is not very easy and becomes even more problematic if there are more of them that need fixing... If you ask if a longer expiry timer works, I would say as far as I am aware yes, but given that we have an issue with a minute timer, I cannot say for sure is not on a longer timer, even if I am not aware of the issue manifesting with a longer than a minute timer...

Send me the workflow (PM) and I'll look into having a sequence to cater for this delay...

[Berto2002]

KE00167283 - Workflows suspended indefinitely at 'Await For Expiry' node that should have resumed. Workaround to use expiry at least 5 minutes.