New Indicators with Same Scores Everyday

[lea26]

I created 3 new indicators in Service Now. The PA data collector jobs are not working correctly. After I execute historical data collector I found out all scores are the same.

For example, this indicator:

Indicator source           Incident Open               Condition: Active=true

Indicator:       Additional Condition: Category is not requests.    

How do I fix that?

Thanks

[sriihs]

Hi Lea,

What is your indicator for? is it for number of incidents created per day or something else?

If you could elaborate some more on what you are trying to achieve, it would help in analyzing the issue.

Also, please paste some screenshots of your indicator conditions and the job collector conditions.

Thanks,

Sowmya

[lea26]

Hi Sowmya,

It's for number of incidents not closed per day.

I had the same indicators set up in our UAT environment and no issue with that.   I only had this problem in our Production environment.

Indicator:

Active Tickets is measured daily as unit #.

The goal for this indicator is not set

It is the count on data source Incidents.Open, which is using the table:

incident

with the following conditions:

Active = true

Additional conditions:

Category != Request

Job collector

Collection parameters : Fixed   Fixed start 1-2-2016   Fixed End Today

Job parameters

Active : true

Run on Demond

Thanks,

Lea

[pieter_goris · Accepted solution]

Hi Lea,

the data collector returned exactly the scores that you asked for .

In your condition you say 'active is true'. When you collect scores, the queries are run against the incident table, not the audit table. So the queries are looking at current values in the incident table. So when looking at an incident that was opened 14 days ago and closed 4 days ago, than currently it is not active. When I run a query right now with the condition 'active is true' against that incident, I'll always get an answer of 0. Even if I would run a query now (with collection parameters for 6 days ago) it is still looking at the current values and thus an answer of 0 as there are no historic values for active in the incident table.

So for historic score collections you should use dates not states! Just stick with the out of box definition in your indicator source. It should look like this:

(If you don't see the last two conditions on the Resolved fields, you probably don't have those fields in your instance and you should add two similar conditions based on the Closed field. Next you should also change a Performance Analytics script. For more detailed information, check this blog FREE PERFORMANCE ANALYTICS: Reconfiguring Indicators .)

So how does this work? The Today operands in the condition are actually placeholders for real dates. These placeholders are filled with real dates during a scores collection. So if I would run it today (Friday, Nov 11) using the job collection parameters set as:

the condition reads like:

Opened on 2016-11-10 .or. Opened < 2016-11-10 00:00:00 and. Resolved is empty .or. Resolved > 2016-11-10 23:59:59

And the score collected would retrieve all open records (that is records without a Resolved date) at the end of yesterday, Nov 10. When I would run this at 2 am, incidents with a resolve date at 1:30 am today would not be included in the score.

And if I would run a historic scores collection for last Friday (Nov 4) with the same job parameters, the condition reads like:

Opened on 2016-11-03 .or. Opened < 2016-11-03 00:00:00 and. Resolved is empty .or. Resolved > 2016-11-03 23:59:59

So effectively it collects the number of open incidents for last week Thursday at the end of that day.

In general you can not do historic scores collections (but have to wait for the trend to build up) for indicators and breakdowns that use conditions, or are based on, attributes for which the value changes during the lifecycle of that record. So instead of using states, use dates!

But even than be careful, especially with 'open records' indicators and breakdowns. (In general the attribute values of closed records do not change anymore.) So you can not accurately collect the number of open incidents/changes/etc by assignment group or by state as these values will likely change. The same is true for an indicator like 'number of open incidents not updated in the last 5 days' as the update date (sys_updated_on) has changed in the lifetime of the ticket. So you don't know what the update date was 7 days ago.

Hope this helps.

Cheers, Pieter