Kevin Kennedy

@James Ainsworth Thanks for clarifying, James, I was not aware of this. Is there a document(s) somewhere that would have told me this that I missed?

@Ricky @James Ainsworth We just added Hornbill's ITOM to our subscription in August. I just set up the Site Integration Server yesterday, and got it working. I tried to create the test Runbook, following the instructions, and I am getting the same error that Andy was getting above, stating "Your subscription does not allow to create more runbooks". Due to my inexperience with ITOM, I have questions. Do I need to obtain a license for each runbook I set up, starting with the first?

@SamS Thank you, somehow I must have missed this page. I have passed it along to our developers.

In our prior helpdesk, we had triggers from a propriatary HR database that produced requests. We have decided to reproduce that functionality in Hornbill by modifying the code in the triggers to access the Hornbill API. So someone ends their employment, HR changes their status to terminated, and that kicks off the creation of a Termination request in Hornbill. We call them Terminations whether the employee initiated the separation, or the company did. Our development team, who have not ever worked with Hornbill, other than manually entering & servicing requests (no automation or API experience yet), sent me a few questions. I was pleased that I (maybe) knew the answer to one of them. The questions asked were: 1. The specs seem to indicate that they are expecting a SOAP WS call – Can we find out if Hornbill can accept RESTFul call with a JSON payload? 2. On the response they send, can they respond via JSON objects? Or only XML response? 3. Do they need to be called via secure web service? If so we may need to know the authentication un/pw? I think #3 is that they need to use an API Key that I generate for the account we want to use for authentication. No idea on #s 1 & 2. Thanks in advance for any clarification you may be able to provide. Kevin K.

@James Ainsworth @Victor So embarrassed that the problem ended up being something you had suggested early on, that I told you was not the case in our instance. Upon changing the two email addresses that were duplicated among out users, and retesting, it seems to be working as expected.

@Steve Giller Thanks for the prompt suggestions. First point was definitely a problem, I fixed it (Red Arrow). I also removed and retyped the condition, basing it on subject, and shortened the searched for text to "Alert" (Yellow Arrow). These seem like very good suggestions, but the result is the same, the email stays unread in the service desk inbox I know there must be something I have done wrong.

@Steve Giller Thank you! I had reviewed both of those previously, and made some changes to test whether any of reasons listed could have been the root cause. I don't think they are, at least to my inexperienced eye.

Hello Relative newbie to the Hornbill world, trying our first go at Routing Rules. Everything seems fairly straightforward, but I am missing something basic. Below are the pertinent screenshots. Can anyone let me know what I missed, I think I have tried all of the solutions in the wiki & forums. Email just sits seemingly unprocessed in the Inbox Thanks in Advance - Kevin Kennedy

@Victor Your wisdom is above question, sir. Maybe I am not describing it properly, or we were attacking the wrong problem. Notifications exist for activities, the activities having previously expired, or remained undone and the request is closed. Technicians want to see the current list of pertinent notifications, not be reminded of what they failed to do 3 months ago, that in most cases is no longer relevant. I guess I was unaware that the activities list could be filtered? The underlying question is "How do we make the technicians list only show notifications for activities within active requests?". The irony is that the technicians see this as a "bug" within Hornbill, when it really is a failure on the Technicians part. (or my part if it was a subject they were inadequately trained on).

@Victor In our case, we are still learning, and the true enemy may be our lack of understanding of the application, and proper methods to use it. These are tasks that are still incomplete (usually expired) attached to long closed tickets. Our Analysts have just recently begun paying close attention to their notifications, and see the notifications for tickets closed several months back. I suppose as an alternative I could have reopened each ticket, opened the executed/executing BPM for that request, change it to force the BPM to continue (although I have had mixed success doing this), and then reclosing the request once the task has been completed/cancelled. However, in my case the writing a report to identify incomplete tasks attached to closed tickets, and feeding the output of that to the HB Task Cancelling Utility seems likely to solve the majority of my problems.

@Victor @lcottell I think I figured mine out. I was unaware of the Hornbill Task Cancellation Tool on Github. I was able to cancel some, although others errored out. It appears that if the request was closed, the Task can be cancelled, if the request is cancelled, the Task ID errors out as already cancelled. I think at this point my problem is solved.

+1 we are also having this problem. Waiting for advice on how to get rid of these expired tasks.

@Mark (ESC) I agree with @Steve Giller's advice, but as we are complete newbies in the Hornbill world, and didn't know any better, I did write something similar for our instance. In our case we had a very limited population of tickets, and the report ran without error. I would advise you if you choose to proceed, to date limit your report to short intervals, to ensure that it runs without error and does not impact your performance.

@Ann K Forgive me for perhaps not understanding your need, but it sounds like you just need to either: 1. Want to hardcode in a date to limit the number of items the report returns, i.e. no entries that occurred before January 1, 2021. or 2. Want to prompt the user for either the earliest date to include, or the dates starting and ending, at the time of report execution. If this is accurate, I can walk you thru the process, as it has been a while since you posted, and no one else has stepped forward. Apologies in advance if I am over-simplifying you needs.

@RobW Pretty late to the party here, so perhaps the need has passed. I just wrote two similar reports to what it sounds like you are wanting to see. My purposes were a little different, the first version of the report shows all activity & communication, what and when it happened, against a single request. As we are in the US and a public company, and our Sarbenes-Oxley auditors often ask for this kind of detail. Like looking at ticket detail, but without access to Service Manager. The second version was to check the tone and frequency of communications from a single user across all requests they interacted with. I have not finished totally validating either report yet, but would be happy to walk you thru the process I used to create either/both of the reports, should you see value in such an activity.