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

+1 - a user configurable option would be great. By default we put tickets on hold 1 week

Good afternoon, I just wanted to report that the "Release" Type is missing from the first grouping within Email Templates: Please can this be added. Thanks, Samuel

+1 to the hyperlink as well. It would be nice to CTRL + Click on the link without having to highlight the reference, copy to clipboard, duplicate current tab (or navigate to an existing Hornbill tab), hold CTRL + SHIFT then click F, paste the reference, press Enter or Open Request. I like leaving the BPM screen untouched (especially if there are multiple failures) and open the requests and instances in separate tabs.

This is a long shot - I'm no expert at all, but I generally find this a reliable way to see what issues could be lurking about on web apps, such as Hornbill (whether due to issues externally or internally). Would it be worth the users navigating to the page(s) they are having issues with, pressing F12 to open the developer tools in their browser, navigate to the Console tab, then hard refresh (CTRL+F5), and sending the information from the console onto Hornbill once it appears no further activity is taking place?

Hi @Gerry, Our Data Team are looking to utilise Release Management and Change Management for Date Warehouse workflows. The idea is to allow customers to raise individual SRs for scripts to be used to load the data into the Warehouse and for members of the Data Team to log one or more release tickets and go through the tickets logged by the customers and using the BPM of these workflows, once they pick up the ticket as an "Owner" a Human Task appears allowing them to associate the SR with any of the available release tickets. There are a small number of people in the Data Team and they may each raise a release ticket for the current week, or for future weeks so they can plan their workload and prioritize accordingly. Once the release is selected in the SR's Human Task, the release ticket is then automatically linked to the SR (I haven't gotten this bit working yet). Other fields on the SR such as the External Reference (even though its internal) is populated with the Release Ticket reference. When a Release ticket is logged via a certain Service and Catalog with bespoke IC and BPM, I currently use the experimental HTTP request node and the Hornbill API to insert the release reference number into a simple list. Once the bpm reaches a certain part of the release workflow, the release reference number is removed from the Simple List using the experimental HTTP request node, meaning that it's no longer possible to associate any further SRs with the release (an existing release would need to be selected, or a new release would need to be logged for a different week), and the current release can then move on to the next stage of implementation and UAT. Our general users don't have access to the configuration side of Hornbill, and we would like to keep it that way (for obvious reasons), and between myself and my colleague who supports Hornbill, we also support other applications as well, so we cannot maintain Simple Lists each time there is a release (and the Data Team are a different part of our Service). This is the reason for requesting automation in this area. If the concern is that it can impact other simple lists, then could we have security measures applied to Simple Lists that determine which ones can be updated via BPM and which ones cannot? Also prevent Hornbill standard ones from being manipulated via the BPM as well? The other idea I just thought about is what about the possibility of having a Dynamic Dropdown List Box Data Query that can be used return a list of Request References (paginated) but we can add filtering to it to narrow down the list. The only problem with this is that Data Queries are not possible via Human Tasks. * I had almost forgotten about this, but I have also got a Power Automate flow that update simple lists via a Webhook when a mobile phone asset is created, and the sub state is "available for customers". This list is used in a Human Task on one of our processes where the officer can select one of the available asset numbers, process the ticket and mark the asset as assigned to a user, the bpm will then remove it from the list and I've not actually had any feedback about it (hence the reason I almost forgot about it) but it appears to be working fine. Again, this is done because Data Queries cannot be used in Human Tasks. I hope this makes sense; it's been quite a long morning for me so feeling drained but wanted to get this response sorted for you. Thanks, Samuel

Hi @Steve Giller I am aware of advice regarding experimental features. I have been told internally this needs to be automated as much as possible so I provided this as a solution, and I am aware the experimental features could change however unlikely, it is still a possibility, hence the reason I have bumped up this request for this feature to be added to the Hornbill Automation, as well as the other post I raised not too long ago regarding having Hornbill Automation for Simple Lists.

Good afternoon, I would like to request for a couple of additions to the Hornbill Automation, the ability to add or delete Simple List items. I can do this easily using the HTTP Request node, but feel it would be better if it becomes a Hornbill supported addition to the growing list of Hornbill Automations. Add List Item Body Headers URL https://mdh-p01-api.hornbill.com/<INSTANCE NAME>/xmlmc/data/?op=listAddItem

I have a parent request which adds itself to a Simple List via a HTTP Request Cloud Automation: In the child request, there is a human task that grabs the details from the Simple List. The ability to link the two requests together using Hornbill Automation would be most beneficial. I'm not having any luck setting this up to work in a HTTP Cloud Automation (I copied the request payload from the F12 developer tools, but to no avail) unlike the listAddItem one and listDeleteItem ones which always works. So I've already +1 this idea above but I'm hoping my update will bring about its attention again.

Thanks @Deen

We get the same issue

+1

Looks good and +1 to the Calendar view as well