samwoo

+1

I don't recall that being possible in the search, so +1

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

Good afternoon, Please can I request for quick links to the Workflow or Intelligent Capture flows in any screens where the BPM and/or Intelligent Capture is specified. For example, when editing a Catalog Item: It would be good to have links to the Intelligent Capture or Workflow from there, for example (notice I added the link icon next to Intelligent Capture and BPM Workflow using the F12 developer tools): This would make life a lot easier when it comes to needing to make amendments, vastly improving the user experience. This can be extended to take the following into account: If there is a value selected in the dropdown or not Hide the icon if there is no value selected If the current user has Workflow and/or Intelligent Capture access roles Hide the link icon if the user doesn't have any roles that grant the access Whether the current user has access rights to the specified Workflow or Intelligent Capture Display the link greyed out and non-clickable if they don't have access, with hover-text that indicates the user doesn't have access to view the Workflow or Intelligent Capture Screens where this can be applied (that I can think of): Service Portfolio -> "Request Type" configuration Service Portfolio -> Catalog Items Custom Buttons -> Select Auto task Board Manager -> Automation Thanks, Samuel

+1 for a node that can be used just Sub-status changes (from and to)

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

Linking back from this topic: Please can I request the following enhancements to add extra suspend actions to the Request Business Process: Enhance "Wait for Linked Request Update" by adding further conditions, such as Service, Catalog etc. Use case: In addition to check for a specific Request Type and whether the update "Contains" specific words, also be able to specify the Service and/or Catalog of the Linked Requests as well. Enhance "Wait for Timeline Update" to include a "Contains" field so we can test for a value on the current ticket (if Request ID is auto) or a specific ticket (if the Request ID has been populated). Also add in conditions to allow checking based on either "Manual", "BPM" or "Both" types of updates. 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 conditions, such as Request Type, Service, Catalog etc. Only allow a single Custom Field to be monitored. 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". Add conditions, such as Request Type, Service, Catalog etc. Only allow a single Custom Field to be updated for Linked Requests. 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 current request (if Request ID is set to auto) or a specific request (if Request ID is populated) and waits for a specific value in the specified custom field.

Thanks @Steve Giller. Here is my first enhancement request:

Linking back from this post: Please can I request an enhancement to "Wait for Linked Request Update" so that it can trigger on BPM update as well as Manual Update. This might be worth having as a toggleable option as some people may only want to look for BPM Updates, others just for Manual Updates and others look for updates from both.

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

Thank you @Steve Giller that makes sense

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?

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: Wait for Linked Request Update Get Request Details (of Release) Decision IF custom field value == "Build Release" then go to 4 else go back to 1 Human Task for "Build Release" Would that be too much for the BPM? Thanks, Samuel

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...

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

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

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

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

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

thanks @Steve Giller

Good afternoon, When using the "Get Request Details" node in the Business Process to update all the Child Tickets using "Linked Requests -> Update Linked Requests" with the details of a Release ticket, everything works except when using the "Schedule Start Date and Time" and the "Schedule End Date and Time" fields, it displays [object Object]. (UAT Date and Production Date are being pulled from the Release Ticket's Custom A and Custom B fields with no problem). Here is the configuration of the "Linked Requests -> Update Linked Requests" node: Here is the Content field. Highlighted is where the result [object Object] appears: This is either: A defect that needs to be addressed I need to specify what to extract in the object ( for example &[global["flowcoderefs"]["getReqInformation"]["scheduledStartDate"].date] ) - if this is the case, what fields are available to me? Please advise. Thanks, Samuel

Good afternoon, Whenever a release is created, the Action Focus is always set to "Schedule". I'd like for this not happen and control the Action Focus via the Business Process. Weirdly though, whenever I suspend the Release Business Process using "Suspend - Wait for Request Owner" with the Action Focus set to "Assign", it always focuses on the "Schedule" action. I'll mark this post as a defect, but it might not be. If it's not a defect, please kindly update the post to "Enhancement". Thanks, Samuel

Hi @Met, Thanks for that. I did figure out the issue out in the end, it turned out that the linkedEntityId requires an array of values (I use JSON over XML, experimental I know). However, I used the "RelationshipEntities" service and "add" method instead, however I shall have a look at the one you used, as that seems straight forward. Here is what the "apps/com.hornbill.servicemanager/RelationshipEntities" service and RelationshipEntities method currently looks like: { "@service": "apps/com.hornbill.servicemanager/RelationshipEntities", "@method": "add", "params": { "entityId": "&[global["inputParams"]["requestId"]]", "entityName": "Requests", "linkedEntityId": [ "&[global["flowcoderefs"]["getReqInformation"]["externalRefNumber"]]" ], "linkedEntityName": "Requests" } } This is what the "apps/com.hornbill.servicemanager/Requests" service with the "linkRequests" method would look like with JSON: { "@service": "apps/com.hornbill.servicemanager/Requests", "@method": "linkRequests", "params": { "parentRequestId": "&[global["inputParams"]["requestId"]]", "childRequestId": "&[global["flowcoderefs"]["getReqInformation"]["externalRefNumber"]]" } } Thanks, Samuel

Thanks @Gerry. The perfect automation would be to allow returning a list of references to a user in the form of a Data Query (available in both the Intelligent Capture and Human Tasks) with filtering capabilities. For example, I just need a list of "new" and/or "open" ticket references against X service optionally raised via X catalog. the raw value would be the reference number, the text value would be something like the reference number + summary. Then the users (mostly via Service Manager in Human Tasks, but some may do it via the Employee Portal) can choose which of the available list of tickets (in my case would be Release tickets) they want to associate the work to and via the BPM the ticket will auto-link creating the parent/child relationship (there is another forum post regarding linking tickets via the BPM). As we don't have main parent/child ticket fields I would store the release ticket reference number in h_external_reference and through the life of the child ticket (the SR), I can suspend and await for certain things to happen on the parent ticket (the release) in my other example above regarding the mobile phone assets, again have a data Query that is both accessibl le in Human tasks and the intelligent capture to allow further filtering of the assets, so optionally filtering on X class, X asset type, X state, X substrate X operational state etc.... Selecting an Asset will return the asset ID as the raw value, and the asset name as the display value. Further to that we should then be able to carry out all sorts of asset automations on a single asset asset. The biggest bugbear is the inability to use Data Queries in Human Tasks. Hopefully I am making sense as I do waffle on, if it helps, I can send you the two bpms (relating to my first point) I have used to get this working with the current set tools that you have provided. I can suspend on the child SR tickets and wait for things to happen in the parent Release ticket quite nicely. Still a WIP though.

Thanks @Gerry for taking the time to look into this. I wasn't sure if any of your responses after my last response relates to my initial query (as well as MacClean's) or if you were you were just responding to MacClean's use case (from what I can tell, it's similar to mine but I tend to waffle a lot in my posts by) but hopefully what I have outlined is similar where the need is to just add or remove values on a simple list where required in the BPM, but in my case the simple lists resides in com.hornbill.servicemanager. iBridge sounds like a good solution.