Estie

In that case given that we are already using the lock resolve action I will raise a support ticket. I am not really sure what the max loop count is - I assumed that this is the max number of times a process is checked eg for if a category has been set yet. Is that the case? I have come to realise this and am a bit confused as to why this is the case I am not sure what the point of suspending the workflow is if the requests can work independently. Something which is causing us extra workload.

@Victor @Steve Giller What I would like is for the category to be set before the incident is progressed. I am expecting that if the category is not set the incident will not be able to be resolved or closed given that we have a lock resolve action node in place in the BPM. Perhaps the issue is not the suspend wait for category but the lock resolve action which somehow appears to be being overridden. About a month ago we revoked a full access role from many of our analysts, which may have caused them to be able to override the lock resolve action. However we are still seeing incidents being resolved/closed without a category.

@Steve Giller- no they haven't. However a large number of the incidents have been resolved or closed. When investigating it appears that the lock resolution action has somehow been overridden. This seems to happen when an incident is reassigned to another team without an owner (before resolution and without a category). This is quite an issue for us.

Hi, We have a large number of suspended workflows which seem to have been suspended indefinitely at the 'suspend wait for category node' This seems to have been happening for a large number of incidents since we started using Hornbill back in 2021. This means that the workflow is not processing other stages - importantly the resolve timer is not being marked, and we are not receiving feedback. Our main incident process has a lock resolve node followed later by suspend wait for owner, priority, and category nodes in the initial assessment stage. The owner and priority suspend nodes seem to be working as expected. The suspend wait for category node seems to have caused many of our workflows to be suspended indefinitely. I have noticed the following in our BPM- - There is no stage checkpoint for the category being set - There is no expiry set on the suspend wait for category - but the suspend wait for priority node which works does not have an expiry set Would these be the problem? Should these options be set in the BPM? If a manual action - ie adding a category - is not taking place what happens to the suspend node? My understanding is that there is a max count loop of 1000 set on workflows. What happens when this is reached? Happy to upload a screenshot of the BPM if needed.

Thanks for the information @James Ainsworth Would it be advisable to lock a resolved request or would that stop any feedback or emails being received from the customer after it is resolved? Would locking a closed request stop any further emails being received from the customer once the request is closed? Is there a way to stop customers updating cancelled requests via email?

Thank you @Victor This seems quite complicated and need to get my head round it. When I have I will give it a go.

@Steve Giller I did exactly the same and doesn't seem to work. However I have now tried your suggestion of filtering on each request status in turn which is producing results - thanks for that. I am still not getting any results for suspended workflows where request status is closed. I initially thought that was OK but have come across some. The reports will make it easier to analyse the suspended workflows. The ability to export the list of suspended/failed/cancelled workflows might be useful to others in the same circumstances - I wonder if this is something you would consider as an enhancement? Thanks again @James Ainsworth @Victor

@James Ainsworth @Victor James - I have tried uploading your report definition file again into a new report and just removed the filter for the request status, but the report is still not showing me any results. I am still unsure on the best way to analyse and deal with the large number of old suspended workflows I have come across. Any further help or advice on this issue is appreciated.

@Steve Giller I am fully aware that many of our tickets will be in a suspended state for any of the above reasons. However we have a substantial number that are from when we started using Hornbill back in July 2021. Some of those tickets are still open in our system. Some of them are resolved or closed. I have already identified one improvement we can make to workflows to stop this happening. However without analysing these I cannot tell what other improvements, if any, need to be made. What is the consequence of me just leaving these as suspended workflows? Presumably they will never be unsuspended if there are errors in the workflow? - eg waiting on an owner when the ticket was resolved without an owner ever being added. How will I know if there is a genuine reason for the suspended workflow or if these are being caused by an error in a workflow if I don't analyse some of these suspended workflows?

Hi Victor, Unfortunately we have 89 pages of suspended workflows - that is over 1000. I need to analyse them to find out the reason they are suspended and see the types of requests and BPMs that may be causing them to be suspended. I am finding it very difficult to filter and sort the list in the suspended workflow screens. Everytime I sort by a column - if I move to another page and back again the sorting is removed. I am also only seeing 22 workflows per page. I need to be able to see all the workflows in one place and filter them and possibly add to other spreadsheets to cross reference data such as resolved by date/resolved by user etc. which is much easier in an Excel spreadsheet or csv. I am happy for any other suggestions.

Yes, it is now working for us. Many thanks.

Hi James, The report you gave me is showing no closed requests with workflow suspended which is good news. I have amended the filter to show resolved requests with workflow suspended which works well. However I don't seem to be able to just see a list of all suspended workflows. I have tried: - the same workflow current status filter (=4) and removed the filter for the status of the request - no results - the workflow current status filter (=4) and added filter for request status = all statuses ie status.open etc - no results. - removed all the filters - get a preview of what I think is all workflows, with all workflow current statuses - however both csv/xlsx downloads are appearing blank. As soon as I try to re-add the original filtering or any ordering/grouping to the report the preview shows no data. Are you able to advise how I would get a list of all suspended BPMs? Many thanks

Issue with Dark mode and High contrast is still affecting us.

Hi James, Thank you this does help. I think you are right about the re-open role. Just so I am really clear - the 're-open' part of the role means re-open a resolved or a closed incident/request? Is there any way to restrict the 're-open' bit to just resolved Incidents/requests? Thanks

Thank you so much @James Ainsworthyou are a star! I will have a go at doing this tomorrow and let you know.

Forgot about the exporting of the list of suspended workflows - is this possible?

Thank you @James Ainsworth these are very good points which is very helpful. I will look at locking the actions. It seems I have a big job ahead of me going through hundreds of suspended requests!

Hi, We have a 2 stage closure on most of our BPMS. However it appears that even though a request is closed our analysts and possibly customers are able to re-open the requests. We appear to have a 'Re-open requests' role (user created before my involvement in Hornbill) - which has the following Application rights: Does this mean they are able to reopen any type of incident or request? ie resolved as well as cancelled? I have checked all the advanced settings and they all seem to be correct. Any help is appreciated. Thanks

Hello, I know this is an old post, however we are in a similar position which has just come to light, where we have a large number of old suspended workflows. There are various reasons for them. From looking at some of the requests associated to the workflows I can see that they have been closed despite the workflow being suspended. I am wondering if I cancel the old suspended workflows will this affect reporting stats? ie where a report looks at the number of closed requests/Incidents? Will the closed requests/Incidents showing suspended workflows still be counted in these reports? Also is there an easy way to export the list of suspended workflows? Thanks

We still have the issue. It may well only affect a few users as not everyone chooses to use Dark mode or change the theme.

Hi we are still getting the error. I have logged out of our instance and back in and tried in Chrome and Edge

We also have the issue

Hi, We have an intelligent capture for requesting visitor accounts, which are restricted to 2 days in length. We ask for the start date, and end date on the form - both use a date control field. The end date that can be entered needs to be restricted to max 2 days (from start date). I can see the use of the date range start and end, however this doesn't take account of the start date. Is there a way to restrict the end date based on the start date entered into the Intelligent capture?

Thanks Victor, How do I setup an ESP to do the following: Show the summary unless it is empty and if it is empty show the following text - 'No Summary Provided'?