Workflow and ServiceDesk Community

After some extensive back and forth internally between deaprtments over data capture best practices in incident management I have come to the grave discovery that the close code field is immediatly overwritten when a ticket reaches the closed status:

I woud like to know the following:

Where in the documentation this functionality is outlined (such that I can re-read it to figure out where my understand went wrong)

From a design standpoint where is the value in having a technician select a data capture element for the process to over-write it.

What options are available to me to disable this functionality and maintain technician selected close code for future reporting.

I took a look at the workflow and it does change the Close Code after the ticket is closed to the values in your closed section. I think it's a design bug as those values shouldn't be changed so you might want to bring that up with Symantec. Unless of course they tell you their reasons for doing it that way but that doesn't make any sense at all since you would want to report on the Close Code.

I also see the issue. What might be better for the process, although a possible pain for Symantec, is that it may be a place for a new table/field where there's a Resolve Code and then a Close Code. I can actually see the benefit of both. The Resolve Code will identify the status of the ticker upon resolution and the Close Code would identify how the ticket was handled or not handled by the end-client when the ticket was actually moved to the closed status.

Yea they would have to add the Resolved Code field to the IncidentTicket datatype in order to do that so I'm not sure if they will. Easiest thing for them to do is not to overwrite it. One of the risks of jumping into a new version right away I guess. 

I guess one thing you can try to do is create a workflow that has a form with the Close Codes and have the person who resolved it select the correct one. You'd call the workflow on the OnTicketClosed ruleset but that would add an extra step and a little bit of work for your workers. Not really ideal but an option.

Or have an automated workflow (no form) that gets called during OnTicketResolved that copies the close code to another table before it gets wiped out by the during the close process.

That's true but then you'd have to create two workflows, one to copy the code OnTicketResolved and one to copy the code back at OnTicketClosed. Good idea.

I was thinking you could just copy the close code off to another table entirely and use that for reporting instead of the standard close code on the ImIncidentTicket (redundent name?) table.

This doesn't work for capturing close code data from incidents resolved from the submission form that only kicks the "OnTicketClosed" ruleset.

Would introducing a new column and using a DB trigger to populate that column help at all?

You're right, the ones that are resolved immediately would still get overwritten with the "Resolved Immediately" code as that is hooked up to the Run Ruleset(OnTicketClosed) component. Ugh, really wished we had access to the workflows to make these changes.

Actually, yes, I could see how this would work. When a ticket is updated on ImIncidentTicket,  the trigger will run. The trigger should check to see if the updated data is changing the 'resolved by' field, and populate a different table to store the actual close code from the pre written data. Then when the ticket gets closed the closed code will be overwritten but our other table can be reported against.

At least, 'resolved by' seems like a good thing to check against. Maybe not, though. I guess you could put the trigger on update to 'ReportProcess' and check to make sure it's setting PercentComplete to 100, but you'd want to also make sure it only tries on IM type processes.

Still, seems possible. Good idea, reecardo!

This was identified recently and will be fixed for the MP1 release of Servicedesk, targeted sometime end of 1st quarter or start of 2nd.