How to set Assigned To user field when null when Incident is Resolved

Nicola_Schubert

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.

Adam_Dzyacky

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.

Adam_Dzyacky

You could have a SCO runbook that monitors for Incidents that move into a Resolved state, evaluate the "assigned to" property, if its empty force the status back to "Active" so it appears in the queue again, OR grab the "resolved by" user relationship and then set it to the "assigned to" relationship and then simply leave it resolved.

This prevents the need to create solution wholly unique to the portal. Not to mention it would work across the portal and console.

Adam_Dzyacky

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.

Tom_Hendricks

I want to add support to @adam_dzyacky's latter idea of targeting the "Assigned To" field.  This is the approach we are currently focusing on. 

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?

Geoff_Ross

@Adam_Dzyacky I'm a bit confused by your answer, which in itself confuses me as you always talk sense.

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

Adam_Dzyacky

Ha, thanks @Geoff_Ross.

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.

Geoff_Ross

Ahh, that makes so much more sense. I agree, often better to train people to use the system as intended than build work arounds.

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

Nicola_Schubert

Thanks for your responses.

Adrian_Mataisz

We have the same situation. Sometimes analysts will forget to assign the tickets to themselves especially when bypass the helpdesk for some tickets/offerings.

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.

Brett_Moffett

Workflows within SCSM would also work for this requirement.
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.

Tom_Hendricks

Brett_Moffett said:

...

Personally, I would go with the second option and stop people using the full Console.

That's what we have done, and it was one of the best decisions made early in the implementation.

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.