you can achieved this by calculating the difference between the last modified date and the open date and the status should be the status what you are looking for you can use either the scoreboard component the difference of time
or you can use other components.
Reporting on the time a ticket has been in a specific state will really depend on your application; however, Xtraction should be able to allow you to create the report if you have the data. In our environment we use CA Service Desk and there is a KPI table that stores the values of several fields, the time they changed and what they changed to. We use Xtraction to view the time the status field was set to valueX and when it changed from valueX to valueY, then we know how long the ticket was in status = valueX. Our Xtraction data model had to be modified to report on this table, but because the application recorded this information, we could easily build dashboards to show how long tickets remained in any status. We also use this table to see how long a ticket was assigned to a specific group, we just report on the group field instead of the status field.
Looking at the last modified date may not work, it depends on what changed in the ticket. As an example, if I change the analyst assigned, I would expect the last modified date of the ticket to change; however, I can't assume that the last modified date - open date will tell me how long the ticket has been in it's current status. What you really need is the time the status field changed to know how long the ticket remained in that status. It's possible you could obtain this information from the ticket log, but again I think it will really depend on the application and what is being recorded.
I agree it sounds like something that would be in a log, status changed at this date but I'm not sure how we pull that in Xtraction from LanDesk Service Desk. I was thinking with it being a LanDesk product now it would be a better tie to their database allowing us to pull the information we need.
jfmascaro is correct.
Ultimately, Xtraction can only report on data that exists or that can be calculated using data that exists. If the data doesn't exist, Xtraction can't report on it.
Unfortunately, most (all?) of the various service management systems that I've pointed Xtraction at over the last 8 years fail to store the necessary information for this type of reporting (or at least fail to store it in a format that is conducive to quick and/or easy reporting). This is an issue with the system that stores the data (the service management tool, in this case) as opposed to the system reporting on it (Xtraction, in this case).
I will check with our internal staff who are more familiar with LDSD so I better understand where/how LDSD stores this information. I will let you know what I find out.
All of our adapters mature over time. With Xtraction now being a LANDESK product, the adapters for reporting against LANDESK products will mature much faster than normal. I've already seen this happening.
Sounds great Gregg, thank you!
What I have found so far is that the tps_audit_trail table appears to have the data we need. However, as I indicated in my last response, it is not in a format that allows for easy reporting. I am still researching a couple of points, and then I'll come back with more details.