Difficulty Processing newly-logged call

[Steve Giller]

I have had a very odd error reported from my Facilities Management Service Desk, it appears to have been introduced with the 1049 build yesterday.

The report from our helpdesk team is as follows:
 

Quote

Logged in remotely to Jo's PC, when she is raising a new job, the green progress indicator is moving constantly between different tasks. When she assigns priorities it is not accepting the change either. It would seem, hornbill is trying to go through some sections of log and priorities of it's own accord and then when nothing has been set, going through them again.

This is in Edge, it also does it in google chrome. When Jo closes or views another job and goes back into the job she is then able to make changes to the job, it's only after she clicks view after initially logging the job that this issue becomes apparent.

It is effecting all staff in the Estates Help Desk.

I have logged in to Jo's PC and created a job using the IT call flow and there were no issues.

 Just to clarify, the progressbar flickers between halfway and completely filling the bar between the Stage 1 and Stage 2 nodes.
On my tests you can assign a priority, but if you're not really quick the dropdown changes back to it's previous value as the progressbar changes length; this has not previously been an issue. Having used my ninja speed to get a priority assigned I am seeing no further issues on my test call.

My tests have been performed this morning, so a complete overnight shutdown of the PC - on that basis it's not a "refresh after an update" issue.

Has anyone got any idea as to what may be happening and why? I'm assuming it's something to do with the way we assign a temporary SLA so we can start the timers and the first task for the Service Desk is to assign the correct SLA.
I've attached the BP that is causing an issue.

 

dev-estates-incident-with-maintenance.bpm.txt

[Victor]

@DeadMeatGF apologies for the lack of replies... I think I understand the flickering issue (I think.. )... but first I wanted to understand the BP configuration:

A. where you assign the "incoming" priority and update service level, followed by timers start... Why are you using the first two nodes (assign priority and update service level)?
B. the priority changed decision loop... I don't see how would work as I think you want it to work (based on configuration). The wait for priority will only waits (suspend) if you don't have a priority (no value).. but you do... you set it in the first node... so it will sort of continuous loop ( which might explain the flickering and you having to quickly select that correct priority)...

I hope I'm understanding this correctly..  (the BP and what you are trying to achieve)

[Steve Giller]

Hi @Victor

I've been off for a bit, but now I'm back:
The issue with the priority (mentioned elsewhere) is that we need the timers to start ticking when the call is logged, which only happens if there's a priority. So, we give an Incoming priority that is updated later. This part is working, to a point. What we either need here is the ability to start the timers when the call is logged, and when the priority/SLA is (possibly eventually!) applied the elapsed time is added - rather like the old Supportworks option of having the email receipt time as the sla timers start time.
The alternative, from what you say above, would be to suspend for a new priority, rather than a priority, which would prevent the looping.

[Victor]

@Dan Munns I think I understand what you want... so I'll tell you how I built our service desk process, I think is what you need:

1. Our SLA has a set of service levels with their own response/resolve timers. The rules will assign a certain Service Level based on the priority of the request. To cater for the scenario when a request does not have a priority, I have created an additional Service Level, which I call, ironically (or not), "No Service Level". In the SLA rules, this Service Level will be associated when the priority does not match any of the above (e.g. when there is no priority). Also, this service level does not have any response or resolve timers... but this is sufficient to trigger/start the timers as wed don't actually need a target yet, it will be set later... So, this "No Service Level" simply acts as a placeholder for the "real" service level and its sole purpose is to trigger the timers.

2. In our BP,  the second and third nodes are "Start Response Timer" and "Start Resolve Timer" respectively (first is "Get Request Details"). This basically ensures the timers are started the moment the request is logged... based on the above, as the request has no priority, the service level on the request, at this point will be "No Service Level".

Having this configuration (1+2) allows you to: have the timers started when the request is logged via the "No Service Level", have the option in the BP to use a "Suspend Wait For Priority" node, which will truly suspend the process as there is no priority yet on the request (rather than having the continuous loop) and have the "real" service level set on the request once the priority is set via the "Update Request: Service Level" node...

[Dan Munns]

@DeadMeatGF.....

[Victor]

@Dan Munns  well... mention fail... sorry 

*sigh... I knew I should have taken a holiday...

[Steve Giller]

@Victor That looks pretty sneaky!
So basically I assign an SLA without a priority and this starts the timers, then I assign a priority (which avoids my jumping issue) and then update the SLA to match the priority as per the rules.

Thanks for the heads-up @Dan Munns

[Victor]

7 minutes ago, DeadMeatGF said:

So basically I assign an SLA without a priority and this starts the timers, then I assign a priority (which avoids my jumping issue) and then update the SLA to match the priority as per the rules.

@danm...   

@DeadMeatGF yes, try it and let me know how it works (it works fine for our service desk)...

Again sorry for the mention I ... well... I can't say much, no way around this either so I have to admit it: Yes, I failed the mention.

[Dan Munns]

I'll let you off this time @Victor  

[Steve Giller]

@Victor I've put that in place - I'll let you know if it doesn't work

[Victor]

@DeadMeatGF it will work.

Doubt in your statement I sense?   (watched too much Star Wars lately)

[Steve Giller]

It was more that I was deploying to the fix outside of the IT Services setup - and when you do that anything can happen.
It did work, though, thanks for the fix.

 

[Victor]

@DeadMeatGF good news then!!

Trust the Force ... (I really need to stop this, too much Start Wars sometimes... )