James Ainsworth

There is very little difference. It is all to do with the association with the request to the service. When editing the form directly on a request you need to make sure that you first look at what service is associated to a request as all requests associated to that service will take the updates. If the request is not associated to a service, then any changes to the form are applied to a default form which is used on any other request not associated to a service or for a service where there have been no previous changes made to the form. Personally, I always make my form edits from the Service just to make sure I'm doing this in the right context. Regards, James

This might be possible, but it might be that after capturing the person it is being raise on behalf of, you would need to change them to being the customer of the request.

Hi Lauren, I have come across some reports of this happening with the app version 1.7.6. I've not seen any reports of it happening with 1.7.7. I will be interested to know which version you are running so we can determine if it is an ongoing issue or if it was fixed in the 1.7.7 update. Many thanks James

Hi Lauren, On my initial tests, I'm not experiencing the same issue. Is it possible to confirm the version of the Android app that you have installed. You can do this by opening the main menu on the Mobile App and select Settings near the bottom. This should then give you an About Hornbill option which when selected will show you the client version. I'm running 1.7.7. I will continue to test to see if I can replicate your issue. Regards, James

Hi @dwalby Thanks for your post. Interesting topic. It will be great to hear about the different approaches from other Hornbill users. Here are a few points from my perspective, but I'm sure that each environment will have a slightly different view on how Major Incidents are managed. Single incident record vs Problem Record: My definition of a major incident is one that causes severe user or business impact. This is an event that should be rare. When a major incident occurs it is an All Hands on Deck situation. I would look to ensure that all the teams, managers, etc, are notified with some responsibilities around confirming that it is a major incident and not a false alarm. (there are some nice SMS integrations that would work well with this type of communication). This may then follow with some communications to the end users. To me a Problem Record is secondary in the process. Possibly after response to the major incident, if the incident has not been immediately resolved, or maybe it has been partially resolved, it might be time for Problem Record to do root cause investigation and have it available for the ''Me too'' scenario for users. (There is a planned change in Hornbill that will allow a problem or known error record to be automatically raised from an incident using the BPM) Should further reports of the same incident be raised as new incidents: I see the incidents as a record between support and an individual. If a user reports an issue, an incident record should be created so that you can maintain that communication with that individual. The prioritization of that incident is a good questions. You don't want to raise another incident with a priority of Major Incident to start another set of notifications going out... or maybe you do. Resolving linked tickets: You would have options here depending on how you want to work. In Administration you can define relationship types between the different types of requests. This would give you the option to link an incident to another incident that has been prioritised as a major incident or an existing problem record. The BPM then has options to update linked requests which includes the ability to resolve. Business wide email notifications: I'm not sure if there are specific functions or features in Hornbill for a company wide email. However, if you have distribution lists set up on your email server, as part of your Major Incident process you could send an email to a distribution group. A BPM triggered email can use templates. Major Incident Report using BPM: I would think that this may depend on what you want to send and who you want to send it to. This might be an email that goes out to selected recipients that simply contains the details of the resolution. If something more detailed is needed, then maybe a task would be generated for someone to create a document in document manager that describes the issue, resolution, lessons learned, changes needed, etc.

Hi Joyce, Could you let us know if there is a particular discrepancy between the dates displayed on an active change, the dates in the h_itsm_changerequest table and what is displayed on the calendar? Are the dates consistently out by a period of time? Regards, James

I'm not sure if there is anything I can suggest at the moment about how to prevent users from setting themselves with a status of on holiday. I'll post back if I can come up with any ideas. James

Hi Hayley, Using the BPM you are able to lock out the assign action on a request. Documentation can be viewed here. Here is a video that shows how this works...

Hi Alisha, Thanks for your post. The Co-worker Search form on progressive capture is not displayed when a user is raising a request from the portal as it automatically uses the name of the user that is logged into the portal, preventing that user from having to type in their name each time they raise a request. We do have some plans to add a User Picker to the custom forms in progressive capture. This would be similar to the existing Group Pickers. This may allow you to create a custom progressive capture form for where the user can search for their co-worker and add them to the request. We are also have another Progressive Capture form for adding Connections to a request. Similar to the Co-worker Search, the Connections form is only available to Service Manager users, but we are also looking at options to make this available to the portal users. Regards, James

Hi @nasimg This issue being looked at is based on the original post which is to do with the length of the list of teams on the Request List. I believe that the other area that you have asked about is within the Administration portal around the creation of users and organisation groups. For functionality related to Administration it is best to post it separately under the Administration topic so that it can be reviewed and managed by the appropriate people. Regards, James

Thanks for your posts. We have an existing change in the backlog for this. I've added you all to the change. @Lyonel this change was created from your original request. This is not currently scheduled for development but I will update this post with any updates to the progress. Regards, James

Hi Even, So far this appears to be working for me. While we continue to look at this I was wondering if you could try uninstalling and reinstalling the Hornbill Mobile App and let us know if that makes a difference. Regards, James

Hi Even, Thanks for your post. We are currently investigating your issue and see if we are able to replicate the problem that you are experiencing. We will post back once we have some more information for you. Regards, James

Hi @aw2215 Thanks for your post. I'd be happy to look into this requirement. Out of curiosity, I would like to understand the intended audience for the Change Calendar and the ability to filter on type. The Change Calendar was seen as a high level overview of changes so that those that have access can get an ideas of when things are coming. For the Change Type, is this value of Standard, Normal, and Emergency, is the audience more likely to be someone who is working the changes and would be managing the changes through the request list? The other great value behind the Change Type would be to drive the BPM to make sure that each change is managed accordingly. Use Cases always help us to make sure that new features are being done in the best way to provide the desired outcome. So, as much information helps, even for something as simple as a filter on a list. For users that are involved with processing changes I would recommend features and functionality to be added to the request list, views, and charts. When it comes to change managers getting an overall high level view of the schedule of changes, then the change calendar makes sense. I'll look forward to hearing back. James

Hi @SJEaton There was an issue that was found where closing a request through the BPM set the value to 0. This has been corrected and 0 is no longer used. This fix will not update your data. It will only prevent it from occurring in the future. For your existing star rating feedback chart, 0 and Not Set are the same. Just that one had the request closed via BPM and the other would have had requests closed manually. I hope that helps. Regards, James

@Martyn Houghton, @samwoo A fix for this was released mid April. I just wanted to confirm if this is now working for you. Regards, James

Hi Claire, As part of the Platform 2914 update there will be a new setting that lets you enable or disable if Handles should be unique. The setting is api.xmlmc.uniqueUserHandle.enable which can be found in administration under System->Settings->Advanced Settings. Setting this to False will allow duplicate Handles and can be done if you are concerned about other issues with imports caused by duplicate handles. Regards, James

Hi Claire, I don't believe that they are related. The patch that was discussed back in March will have been released as part of a regular update if your instance wasn't patched at the time so I'm assuming that aspect will be working for you now. I believe that the restriction on the Handle being unique is going to be removed. Regards, James

Hi Giuseppe, That is correct. It will be evaluated as you suggest and added to our backlog if it is something we can provide. It will then go through a process of prioritisation within our backlog of changes.

That's great news @Stuart Torres-Catmur. Thanks for letting us know. James

That's good to hear @Stuart Torres-Catmur. Thanks for the feedback.

Hi @Michael Sharp A fix has been completed for this which was released in the Admin update (build 830) that was available as of Friday. Can you confirm if this is still an issue for you, with administration build 830 installed?

@Stuart Torres-Catmur 1228 will have included the fix which was provided in 1223. While this shouldn't be the case, I wonder if the browser's cache needs to be cleared as mentioned in DeadMeatGF's post above.

Hi @Martyn Houghton In this case the Auto option is looking for a variable of a particular name in order to make this assignment. Unfortunately there is a mismatch between the provided variable and the Auto option. This is being looked at by the development team.

I think that having ticket 1 wait for tickets 2 to n to be resolved before ticket 1 is closed might be a challenge. When working with a single request, this is where the parallel processing works well. I think that there are definitely some ideas here that we can think about with how to increase some of the automation between tickets. Something like a Suspend and wait for all linked tickets to be resolved/closed.