Helen Chaytor

This has been resolved for new calls raised since the beginning of December.

Hello, The recent ESP 3783 update said: Fixed a problem with MSP mode not being reported so UI was not reacting accordingly. Does anyone know what MSP mode is?

Is there any update on this issue with resolution timers no longer reliably stopping since the Hornbill update on 19 July? It's still a problem. Thanks.

We had a similar problem yesterday between 16:45 and 17:10:

That explains it. Our Service does not have a Default Workflow. We'll try this again after the next upgrade.

The original call (IN00025608) is currently in a resolved state. Looking at the timeline it would have been in a resolved state when it was copied. Yes:

We used the Copy Request feature to raise a new call this morning based on a call logged earlier today. The new call created did not have SLAs attached and is not visible in Manage Executed Processes (view below is 'All Non-Completed', I also checked 'Completed'). The new call is IN00025614 and should be between the 2 that are visible. Is this how the Copy Request feature is supposed to work?

These are the settings of our Mark Response Timer node. Can you spot anything with this? I copied it from an example Hornbill process provided when our system was implemented last year and I copied the same version of the node into about 40 business processes. Thanks.

Some of our calls are failing to mark the response timer, even though the business process starts and then should end the response timer. This example is from one of our calls raised today by an analyst and when I check the Executed Processes in this business process it clearly shows that the timer has been started and that the flow has passed through 'Mark Response Timer'. However, the response is still apparently outstanding and we have no way to manually change this to mark the correct response time. If anyone has an explanation for why this is occurring or what we need to do to fix it I'd appreciate it. 0.000009s INFO Workflow processing started, processId=BPM20201111000020 workflow=com.hornbill.servicemanager/mkc-incident-process (revision=27, type=businessProcess) 1.302545s INFO Process Flow Transition from 'Set status to New' (id=flowcode-4e21ffbe-e6cd-4ade-c456-6841d6fa569f, type=HornbillAutomatiomn) to 'Start Response Timer' (id=flowcode-285a5c9b, type=HornbillAutomatiomn) 1.627795s INFO Execution Step: currentStage='s1', currentNode='flowcode-285a5c9b', suspended='false' 1.627839s INFO Unsuspending process at node 'Start Response Timer' (id=flowcode-285a5c9b) 7.799079s INFO Unsuspending process at node 'Start Response Timer' (id=flowcode-285a5c9b) 7.799092s INFO Process Flow Transition from 'Start Response Timer' (id=flowcode-285a5c9b, type=HornbillAutomatiomn) to 'Start Resolve Timer' (id=flowcode-0c9da96b, type=HornbillAutomatiomn) 16.389093s INFO Process Flow Transition from 'Set Status to open' (id=flowcode-e0573962-66db-4fae-54a5-a3344d0bd44b, type=HornbillAutomatiomn) to 'Mark Response Timer' (id=flowcode-4e2d786b, type=HornbillAutomatiomn) 16.616713s INFO Execution Step: currentStage='s1', currentNode='flowcode-4e2d786b', suspended='false' 16.616743s INFO Unsuspending process at node 'Mark Response Timer' (id=flowcode-4e2d786b) 17.537175s INFO Unsuspending process at node 'Mark Response Timer' (id=flowcode-4e2d786b) 17.537193s INFO Process Flow Transition from 'Mark Response Timer' (id=flowcode-4e2d786b, type=HornbillAutomatiomn) to 'Next Stage' (id=nextstage-d2f5f2e4-7f35-29ce-1c86-046e37a2039e, type=StageComplete) Call shows response is still outstanding:

Thanks for responding. I don't think so. I've looked on the Executed Processes screen for one of the calls without the response timer marked and it is showing that the call has been through the 'Mark Response Timer' node: 10.492145s INFO Process Flow Transition from 'Set Status to open' (id=flowcode-e0573962-66db-4fae-54a5-a3344d0bd44b, type=HornbillAutomatiomn) to 'Mark Response Timer' (id=flowcode-4e2d786b, type=HornbillAutomatiomn) 10.510791s INFO Execution Step: currentStage='s1', currentNode='flowcode-4e2d786b', suspended='false' 10.510838s INFO Unsuspending process at node 'Mark Response Timer' (id=flowcode-4e2d786b) 11.036172s INFO Unsuspending process at node 'Mark Response Timer' (id=flowcode-4e2d786b) 11.036187s INFO Process Flow Transition from 'Mark Response Timer' (id=flowcode-4e2d786b, type=HornbillAutomatiomn) to 'Next Stage' (id=nextstage-d2f5f2e4-7f35-29ce-1c86-046e37a2039e, type=StageComplete) However, the call does not have the response timer marked: This particular example is from our incident process, so it's well-used and mostly working. The only thing the problem calls seem to have in common is that they're raised by analysts rather than coming through self service. But again most calls raised this way are fine.

We have recently implemented SLAs into Service Manager. We're automatically marking the response timer in our business processes when the call has an owner. We've had a couple of odd calls come through where there is an analyst allocated but the response timer hasn't been marked. Removing and re-adding the analyst also doesn't mark the response timer, so these ones are going out of time. Is there a way to manually mark the response timer on calls?

Also for Milton Keynes Council. 'Failed to initialize application'