Options
How to set Assigned To user field when null when Incident is Resolved
Nicola_Schubert
Customer IT Monkey ✭
Hi All
We have a lot of situations where our Analysts are not Assigning their tickets before Resolving an Incident.
Has anyone come up with a neat way of either setting this field automatically when the Incident is set to Resolved OR not allowing the Incident to be set to Resolved if the field is Null.
We do not want to make the field mandatory unless it is Resolved.
Any ideas or clues would be appreciated. I am a newbie to writing custom js.
Thanks
Nic.
0
Best Answer
-
Options
Adam_Dzyacky
Product Owner Contributor Monkey ✭✭✭✭✭
Another thing that just struck me is that you could accomplish this by writing your SCSM DW reports against fields like "Assigned To" in order to properly give/establish credit to analysts who worked/solved items that month.
This completely gets you off the hook for having to invent process to curb bad process because from management perspective it may put pressure on analysts to follow process in the first place. Although if you're also the one writing the SQL reports...
Just thinking outloud here as there are a lot of ways I think you can address this issue.6
Answers
This prevents the need to create solution wholly unique to the portal. Not to mention it would work across the portal and console.
This completely gets you off the hook for having to invent process to curb bad process because from management perspective it may put pressure on analysts to follow process in the first place. Although if you're also the one writing the SQL reports...
Just thinking outloud here as there are a lot of ways I think you can address this issue.
Also, while I am not able to mock this up at the moment, it should not be too difficult to create a task to populate the Assignee field with the current user if the status is Resolved, but getting it to trigger on save is the part I have not personally worked with yet. Perhaps someone else has more experience capturing that event?
If they run a report off the Assigned To field, there will be gaps as the issue here is that Analysts are not assigning to themselves, just grabbing out of the queue and resolving.
@Nicola_Schubert I would look into a custom resolve task that first checks that the Assigned To is populated before allowing a resolve or that also sets the assigned to when resolving.
Geoff
So yes, my point about "writing reports that target this, even though the field is empty" - is absolutely not addressing the gap in data. It very much is leaving the field empty! It is however creating a talking point amongst management to analysts along the lines of "You aren't receiving credit for the work you're doing since you aren't assigning Incidents to yourselves."
I've seen this tactic used a few times because it avoids creating a technical solution to what I would argue is a management problem. However! HOWEVER! As a bit of an automation snob, it's not to say I couldn't argue it the other way - we have technology/automation, why wouldn't we just use it to curb "bad" behavior? So again, not really saying it has to be one way or the other, just thinking/typing outloud on ideas to address these types of issues. I hope my explanation restores order in the galaxy?
Ultimately the decision seems to be based entirely around workload of those supporting SCSM, writing reports, creating automation, etc.
However, just to add (and this does relate to the initial issue @Nicola_Schubert) that I have worked with many IT Departments and in general, those that publicly monitor and gamify how many work items are resolved / completed by each analyst don't perform well and they create a culture that rewards quick fixes in high volume over full, route cause resolution which takes time.
Anyway, just my experience, and a generalisation.
Geoff
We don't want to make the analyst field mandatory because we use Assign to Groups but in the same time it would be nice to have the Change Status task check the analyst filed when status modified and auto-filled it with the analyst name.
Setup a workflow that runs when a WI goes from Not Resolved to Resolved and Analyst is NULL
Have it apply a template that has the status of Active.
This will re-activate the WI until such time as the work item has an analyst entered.
A better way to do this would be to not use the console and write this functionality in to the Cireson Portal.
When the Change Status task is selected and the status is changed to Resolved or Closed and there is no Analyst assigned, you could have a warning appear on the screen asking the analyst to either enter an analyst or give a reason why a user was not assigned.
Personally, I would go with the second option and stop people using the full Console.
I am sharing this both to reassure anyone considering the same approach, but also to make it clear that any feature in the console that is not also in the portal is totally unavailable to our users. Therefore, when there are feature requests for portal parity with the console, there is some urgency to it. Having said that, the vast majority of analyst users (and all end users) will not even notice anything that is missing because it isn't part of their workflow.