Berto2002

Hi Victor, that sounds interesting. Perhaps we've missed this piece of education. I understand the concept here. A couple of Q's please: 1) Are there any articles referring to this in case there's more to know about it? I could not find reference in Wiki 2) It feels to me that I would be going live on an untested BP but are you saying this is the 'official' way to do this and that the download/upload process carries-over 100% of the the config and can be relied upon for this as the release mechanism? Thanks, Berto

I am afraid the way this works means the Rename option is almost completely pointless since there is almost never a time, after a process has been set into motion, that it will ever not have at least one ticket using the lifecycle; and therefore can never be renamed. Even in test we have loads of tickets so our test processes cannot be renamed either. It's bad. It should work that a new Request takes a snapshot of the BP at that time and works on that copy for it's lifecycle. If the main BP then alters (such as a name) that's fine, the next Request that comes along will grab the latest version/name. This facility is already in place with the versioning of the BPs in the editing window. As it stands, if I want to make a major change to a BP, I have to copy the Live BP and give it new (permanent) name. Then, when I have finished with the testing and want to go live, i am now FORCED to locate and edit all the Catalogue items that use the current live BP and edit them and re-publish them to use the new BP. Effect: I can never have a release system that means the live BP's are all called "[Business process Name] - Live" and all the test BPs are called "Test". I have to name my test BPs as if they are Live and then somehow tell everyone they are not! Really suggest this needs some re-thinking at HB. At least provide a one-click facility to find and address all the existing Requests preventing the renaming so we can clear the way. I can search for them but the links are not active so i have to manually open them one by one...

When our Hornbill Service Manager was put in place, our consultant set-up the PCF Questions to capture all the information like Implementation Plan, Rollback Plan, etc. But then we found out such information could not be edited later in the lifecycle. Our last internal Administrator then moved to capturing the information using Human Tasks for each 'Plan' and posting them to the timeline. But now we find that not only does this mean the parts of the plan are scattered down the Timeline but editing them is doing just that and not actually altering some underlying content that can then be used later. All we seek is a way for all the core fields relating to building the Change Request to be stored and editable through the lifecycle (i.e. if the Peer Reviewer asks for more info, or the Change Manager does or CAB does. They would then be fixed at the point of submitting for approval/authorisation. I cannot help but think that neither of the ways we've seen are very good. The requirement here is very simple and should be easy. How can the Requester be given a set of fields to use to build-out the details of a Change, editing when required? What facility are we missing in Service Manager for this?!

I couldn't resolve a ticket. It looked like there was an Assignee and I could not click "Assign" but Service Manager claims No Owner. I had to refresh the ticket before the Assignee disappeared and I could then assign again to resolve.

#Facepalm Steve, I've been shown as a rookie again and did not see that Variable. Thank you. I will try this. Any way to do the other option I suggested, for future reference? I.e. to set-up parallel processing with two streams - one with a Human Task and the other an Await Expiry node - wherein the completion of either node automatically completes the other node (i.e. over-rides the wait or completes the HT); and thus satisfies the end of parallel processing so I can trigger the second, escalation HT Or to allow parallel processing to operate a first past the post system and be satisfied to continue even with fewer than all parallel streams being satisfied?

I have a logic problem I cannot solve. Can you help, please? I want a Human Task that Service Desk can act upon if they receive Leavers' hardware returned early but to have that task 'disappear' and be replaced by a different Human Task (escalation) if the Line Manager does not return hardware by an expiry date derived from the PCF completed when the Request was logged. The logical ways I can conceive of this working but cannot work out how to configure are: to expire a Human Task based on a variable. This would then directly replace one HT with another after a period of time. There is an option to expire on a set period since creation of the Task but not refer to an external value as there is in Hornbill Automations or Expressions to set-up parallel processing with two streams - one with a Human Task and the other an Await Expiry node - wherein the completion of either node automatically completes the other node (i.e. over-rides the wait or completes the HT); and thus satisfies the end of parallel processing so I can trigger the second, escalation HT At present, I have had to be satisfied with having a wait step (with a Notice to Service Desk to wait, and suspend of all actions) and the Human Task for the action only appearing after expiry. Any help appreciated. Thank you, Rob

I skimmed them and then Harry disappeared. But I am being asked questions on the content so where do I find those updates again to read and pass-on?

Reference: IN00167847

OK thank you. We will raise a Premier Support request

Hi Victor. I have this basic flow: In the Human Task I have this Field Capture Then I map the data to customer_g: Then I Get Request Information and trigger an email. I am testing with only a few chars so should be within the tolerance for custom_g: "VARCHAR custom fields a - o each suitable for holding up to 255 characters of any type." The email then has that custom syntax in it and it doesn't ever give data; in either the summary or the body. Am I doing anything incorrectly? Cheers, Rob

Hi, I am having a similar issue. before I ask a stupid question, can you please point me to where on the Wiki I can learn about inserting what I call active/dynamic fields into the text? I am having trouble with the insert in yellow not working. The green one does work. If I can see a Wiki page which has all the references to this I may be able to work it out.

@Mohamed I need to tidy-up now so I'll go ahead and make the rest of the multi-ticket updates. We have fixed our workflow now so we won't get this recurring on Incident but I will be back to do the Service Requests in due course so if you need anything more from me, let me know. At present, I think there is something in the software that's stopping it...

I believe there is a Hornbill design flaw here. This is my thinking: When I put a request on hold, I get a box that asks me to enter a Reason and that has a visibility setting where I can select Customer. However, this DOES NOT send an email to the customer. However, when I place an normal update on the request using the Comments feature, and I select Customer, Hornbill DOES send an email: These two GUI features should invoke the same options for sending. My Business Case is that my Users want to receive emails for manifest updates (like going on hold) and my Service Desk do not want to have to enter an update in TWO places. My workaround is that I am going to disable the Reason field on the On Hold sub-status which will then ensure the Service Desk use the Comments to update the customer. Unfortunately this is a little bit of a productivity hit since they have to update the request in TWO places when putting it on hold. My request is that there be an option introduced to enable the email customer feature from the sub-status box (or it invokes the same send options as for Comments). Rob

Morning, In the attached example, I attempted 4 tickets. It completed the final one on the list first (...7364) and then got stuck. I wonder if order is a thing here. I noted that that ticket that processed was 'white' not 'blue'. Maybe that has a bearing. Only one of those tickets was assigned only to a group, not an individual but I cannot see how that would affect it. None of them had any open Assignments/tasks. They are all using the same Incident workflows and PC forms. What else can I get you?

I have now completed the batch of work but did so in tranches of only 4 tickets and that worked every time. So maybe there is an issue with batches over 4?

Hi, I have started using the Multi-select to fix some data: Multi-Select Actions - Hornbill But I cannot get more than between 2 and 4 tickets to update at once: the process stops processing before completing most of the time but does not give information as to why. In the attached screenshots, you will see I selected 10 Email support tickets and the process stopped after doing 60%. I closed the browser, repeated my search and then found 4 tickets remaining; which I then completed with another run. I tried again with another category and it got stuck on 33% of 6 (i.e. after only 2 being processed). What am I doing wrong or is there an issue here? Thanks in advance Rob

Hi Steve. Thank you. I will take-away learning to search both the Wiki and Forums before posting here next time. :-)

When in a Request list, you can tick a ticket in the left column and this little box appears: The purposes is to update multiple tickets with one action as stated: But as soon as I select the second of my list of tickets, the box disappears! So we cannot use this function. Are we doing something wrong? BTW we are selecting only tickets of the same type if that matters. Anyone offer any suggestions or do we have an application issue here? Thanks, Rob

Hi. I confirm this issue is now rectified for us. Thank you.

Our Impact Assessment is broken. It returns UNDEFINED result despite us having made no changes in the system since yesterday and the calculations and thresholds are correct. Suspect the latest release has caused this issue. At present, we have to add a catch-all condition in our change process to ensure workflow moves beyond the assessment and ask people to complete that manually. I have logged this as an Urgent Issue through Premier Support portal