Where/How does SNOW get the day/time data for trend charts?

[raking08]

We need to create a trend report but I am not sure if OotB SNOW can do this.

We have a custom table of about 6k rows of "content". This complex content is "graded" and the results maintained weekly or monthly in a "grade" field which is a picklist (A,B,C...)

When I create a trend report I only get the one column as there is no field for "last graded" so I am missing the "timestamp" that SNOW is using to create the trend.

Is SNOW using u_created (which has no relation to what a grade was on a particular date) or is it using a timestamp based on when the report was run?

EX:

for group 1 on April 1 the grade summary was A=0, B= 0, C = 5, D=400, F=500

On May 1st the same records were regraded and the new data for the same records was A=5, B= 100, C=150.....

Using the fields u_created and u_updated wont do as many other fields in these tables are being managed

no matter what I do I only get a single column of results with no date on x-axis.

Somehow the act of running the report needs to collect the data for that day and store vs previous data so that the trend can be seen.

Can someone point me in the right direction?

THX
RAK

[dmaze531]

You should be able to chose the trend range   in the Report details. If your specific range isn't there, you can create a new range.

Trend Charts Generally (notice the "per" option under Step 3:   Trend reports

Create new ranges: Report ranges

Helpful? or Solved?

[raking08]

Hey Daniel,

Yes I get that, but regardless of the frequency I choose, I get one unlabeled x-axis bar. I get one bar even after running the report 20 times over a few days. Somehow I am not getting the timestamp on this field. (It is a choice field)

I think my root question is what is SNOW using for the timestamp? if its the standard create date on the custom table then this approach will not work. If it is recording changes for this field (what I thought report ranges might help with) then its not accessing it. As a reminder, I have a field i a table that for individual records changes over time so u_create/u_updated are not helpful fields as they pertain to the record and not this one specific field.

To your last point, when choosing "per" day/week hour etc.. nothing is happening I still get one column with an empty time label. If the time stamp is in the report based on when the report was run, then somehow my Trendline is not able to access that data.

I may need to brut force tis by customizing a results table that manually captures the view of the data (the 6k records) on April 1 and when I rerun on april 15, it stores the new data for the same 6k records.

Does that make sense?

thx for responding and I appreciate all ideas

r

[dmaze531]

Ah, I think I understand your question now.

Is this correct? If have one piece of work or widget. This widget has a lifespan that a period of time (weeks, months, etc). Over the widgets life, the GRADE may change (from A to B, then back to A, then maybe C). You would like to report on how this widget's grade changed over time? However, all the system shows is the last grade?

If the above is correct, then you are correct that the basic Reporting Engine will not report on CHANGING data over time. It can only report on the value of the field AT THE TIME the report is run. (Example: On Jan 1 the widget was graded as A. On Feb 1 The Widget Grade was changed to B. On March First, you run a report for Widget Grades from the time period of Jan1-Jan30. The report will show GRADE B. Whoops).

To deal with changing values over time you have two options: Performance Analytics or Metrics (assuming you want to stay in platform). For Metrics: You need to define a metric to capture the changes to the field over time and then report on this. This would involve activating the Metrics plugin and creating a new Metrics Definition. You would need to script the calculation as well.

http://wiki.servicenow.com/index.php?title=Metric_Definition_Support#gsc.tab=0

Out of platform, you have a couple of options: You mentioned a custom table to store the results over time (as you guess: this is ALOT of data to store and manage and platform is not really equipped to handle that time of data set with your use case) or dump the data out of platform (manually or automated) to a third party tool.

[dmaze531]

To answer your question directly. There is not a time stamp for individual field updates. The system will time stamp the RECORD anytime any field is updated and store this time stamp in the updated (sys_updated_on) field.