Can business processes get information on linked requests?

[JJack]

I'd like to extract and act on information from one or more linked requests.
I can see a business process can create, wait for, and also, as a group, update and resolve linked requests.
Is this all or is there a way to get a linked request reference number that could be used as a manual request id to a Get Request Information node?

I can't see a way to read timeline information either.

[Jim]

IF big IF but if you could get the ID of the request maybe in a task, you could just replace the request ID from 'Auto to the actual ID you want, automatically, not so easily especially if you have multiple linked requests

 

I do a similar thing in our MI's except rather than analysts manually linking I make an api call to link the request from a field in a task, that way analysts don't feel like they are doing the same thing twice

[samwoo]

As Jim said, you can populate the Request ID field in the Hornbill Automation nodes with a different request reference if you want to grab data and/or suspend and wait for something to happen, however you are limited in what you can suspend a Workflow for (for example, if you want to check the custom field of another ticket has a certain value or not).

See my thread here where I outlined the challenges I faced doing this, as well as links to two posts I created, where I have requested for enhancements for further suspend options in case you want to vote them up.

To see how you can populate the Request ID field, see the post by Steve Giller (from Hornbill) on September the 8th, where he included a screenshot showing this in action. At this point I had already been doing this, but didn't include any screenshots to show it.

One notable challenge is capturing the reference of another ticket. In most cases, this requires manual input, and currently, there's no validation mechanism to check the validity of manually entered ticket numbers against the system, at the point of entering this information in.

However, you can add Regex validation to ensure the correct format, such as SR0001234.

Whether you or other users populate it via a question in an Intelligent Capture form (e.g. to h_custom_a) or via a Human Task in a Workflow (e.g. Update Request Custom Details -> Custom Field A with the value from the Task), adding validation/checks within the Workflow is advisable.

Within your Workflow, consider implementing a validation process. Begin by checking the reference using a Get Request Details node on the Current Request (Result Reference = getReqInformation). Then, branch out to another Get Request Details node (ensure you change the Result Reference, perhaps to getOtherRequestInformation) to retrieve information from Custom A, which would be where the other request reference is storedf. Utilize a Decision node to check the results.

If the request reference from the Get Request Details node (getOtherRequestInformation) is not set or if the ticket is of the wrong request type, category, or service, or anything else from the request details, you can use the decision node to trigger a new Human Task. This task can inform the user that the supplied ticket is invalid and request another input in the Human Task. Subsequently, you can update h_custom_a once again, and the validation check will take place in a loop. If the conditions are satisfied, then the Workflow can move on.

Thanks,

Samuel

[Berto2002]

You will also have the issue that there may be multiple linked Requests so a call to "get linked request ID" may return multiple answers; and each could be of a different type so will not all contain the same fields.

I can think of one way you can get around this but only if your starting Request 'spawns' the other Requests:

1. use the "create new request" node in Request1
2. store the resulting request ID (Request2) in a custom field on Request1
3. then you can reference that Request2 ID specifically and do a "get details" on it later from within Request1
4. You can repeat the above as many times as you have custom fields to store the individual Request numbers for spawned requests

You will not be able to read the timeline of Request2 from Request1 but the Request2 workflow could store whatever values Request1 needs into a custom field on Request2 which could be discovered by the "get details" query in Request1.

Just an idea...

[JJack]

I think I've concluded that what I want - to get a linked request id automatically - is not possible. I would have liked it if there was a call to get linked request ID but I haven't found one.

Many thanks for your help @Jim @samwoo @Berto2002, there's quite a bit in your posts for me to consider for future reference!