Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Ticket History details.

Created: 30 Jan 2013 • Updated: 26 Aug 2013 | 14 comments
kareddy's picture
7 Agree
0 Disagree
+7 7 Votes
Login to vote

It would be nice to have a detailed log of ticket in history not just the process message which just give the task type performed and by not how performed.

Example:

1. Say an environment has few queues and a ticket is sent among 3 queues one after other. Than it do not show the queue names or other details.This is how it shows after removing process messages. There is no wat for the managers to track the change except if the support add comment and specify the queue chnages.

Comments 14 CommentsJump to latest comment

Wynfair's picture

Have you tried adjusting the filters in the history? Under the Process History section click on the Filter button. I selected all except the one called "Only Last Comment". After doing this much more was displayed in the history than just the satus change.

0
Login to vote
kareddy's picture

I did Check it but it dosent show the details of from which queue to to which queue the incident has gone through.

0
Login to vote
michael.george's picture

In order to add that 'natively', we'd need to be able to edit the incident management workflow itself. However, here's an off the cuff idea for you:

Step 1. Setup a new workflow that adds the comment you want to the incident history

Step 2. Create an automation rule for 'on ticket assigned' that send the incident to your custom workflow

If a post solves your issue, please mark it as a solution. It makes these forums better for everyone.

+1
Login to vote
Dan B's picture

Is there a way to perform full lifecycle reporting?  There is a need to show all participants throughout the process.  

Adding a workflow so Support and Management staff can see these details would help for those working on tickets but management require much more detail.  Ideally a timeline showing full lifecycle of a ticket.

Will adding this workflow allow these details to be reported on easily?

0
Login to vote
michael.george's picture

Easily is an tough call. Yes, you would be able to report on it as it would have put entries into the ticket history. Easily? Well, that depends on your skills in the SD report creator and/or SQL and what you want the report to look like. A basic report that wouldn't be too hard would show the ticket(s) as a top level item and underneath each ticket a date ordered list of each person that moved, resolved, or commented on it, and I think that wouldn't be too difficult. Obviously, a report of every ticket listing this information would be a very bad idea potentially as it would be rather large and viewing in the Process Manager reports page would likely timeout.

If a post solves your issue, please mark it as a solution. It makes these forums better for everyone.

0
Login to vote
Lark's picture

I think many of the workflows are lacking sufficient logging of detail.  Ideally any change to a ticket would automatically record the original value and the new value.  I build this into any of my workflows by default.

Even better would be somewhere in the ProcessManager that would allow us to choose what types of events were logged in tickets.

0
Login to vote
Lark's picture

I just tried michael.george's idea of using a workflow triggered by the OnTicketAssigned ruleset.

Unfortunately it looks like the ruleset triggering occurs BEFORE the ticket is saved by the "Reassign Ticket" dialog model (I think I've described that right).  So an external workflow that is passed the IncidentID still only sees the old queue the ticket was assigned to - because it hasn't been saved at this point.

So any process message you might record would only reference the old [Incident.CurrentlyAssignedQueue.QueueName], not the queue you're moving it too.

Has anyone else got this working?

0
Login to vote
michael.george's picture

That's not too surprising in retrospect. I wonder if you could pause the workflow execution for a few seconds to let the reassignment catch up?

If a post solves your issue, please mark it as a solution. It makes these forums better for everyone.

0
Login to vote
Lark's picture

You mean somehow have the triggered workflow wait but allow the core incident workflow continue?  Is such a thing possible?

0
Login to vote
michael.george's picture

It is. The 'pause execution' componenet would do exactly this. That's whay Jason included it, and a loop with counter, in his 'send incident to workflow' template.

https://www-secure.symantec.com/connect/videos/servicedesk-customization-send-incident-workflow-ruleset-action

If a post solves your issue, please mark it as a solution. It makes these forums better for everyone.

+1
Login to vote
Lark's picture

Ah yes - I was using Jason's template but hadn't paid too much attention to the looping pause that was waiting for the incident ticket to be created.

I tweaked my workflow to collect the current Incident.CurrentlyAssignedQueueName, put that into a temp variable, pause the workflow for 15 seconds, re-read the Incident Ticket and then write out a process message stating the old and new queues.

I had assumed the ruleset would wait for the called web service to complete but now I know better :-)

I don't like the pausing approach in general as its too subject to variances in the server's current state/performance but its a reasonable workaround until Symantec implement kareddy's good idea.

0
Login to vote
Dan B's picture

In other systems we used a Temp - Read Only Field to hold the history data,  then when the record is saved to the new queue. 

This allowed us to record information which has not been recorded at the time the ticket is saved.

Otherwise I suspect you would need to trigger a new workflow after the ticket is saved for any action requiring a history entry.  But that sounds like redundant code when all we really want to do is update the history at the same time the ticket is assigned/saved.

0
Login to vote
Dan B's picture

Didnt finish ...

In other systems we used a Temp - Read Only Field to hold the history data, then when the record is saved to the new queue both the queue change is applied and the history entry

0
Login to vote
africo's picture

here's a process i'm using to get around what you're talking about.

rather than looping anything, i'm just sending the runruleset component an "all done" command then fetching the new data after a short pause.

pauseworkflow.PNG
0
Login to vote