what is the fact table for service request table for indicator source we need to select.

[Geetha7]

what is the fact table for service request table for indicator source we need to select.

[DJL2 · Accepted solution]

Replicate the daily and historical jobs for Incident, name them as SC Task Jobs and attach your SC Task indicators to them.

[Geetha7]

Hi,

I need to pull some data. Assignment group= A. Resolved last 3 months. I need this data how to apply these conditions and in indicator sources or indicator?

Regards,

Geetha.

[DJL2]

Hi Geetha,

If I was approaching that, I'd do the following:

Indicator Source

• Table [Incident]
• Resolved on [Last 3 months]
• Contact type is not [Event]

You could name this Incident.Resolved.Rolling3mths

Indicator

• Name: # of Resolved Incidents (last 3mths)
• Unit: #
• Indicator source: Incident.Resolved.Rolling3mths

At this point, I wouldn't declare an Assignment Group as a condition, as it is restricting.  You will be able to see the # per Assignment Group as a Breakdown...

• Breakdowns: chose whichever you need, in particular Assignment Group 😉
• Job: entirely depends on the required sensitivity: daily, weekly, monthly etc

Then hit apply on the final screen.

After it has created your indicator (along with any historical records) I'd suggest creating a Breakdown widget, where the Indicator is: # of Resolved Incidents (last 3mths) and your Breakdown is: Assignment Group.

This will populate all scores, per each Assignment Group.

Hope this helps and produces the outcome you're after...

Thanks,

DJL

[Geetha7]

Hi DJL,

Replicated same incident daily and historic jobs as sc_task jobs and attached to indicators and ran the jobs. But it shows records inserted is 0 and also some errors."

Fetched too many rows from indicator source SR trend weekly.closed. Allowed: 50,000 fetched: 58,255"

I have given some conditions only in indicator level. Like closed on this week , state is closed etc.

[DJL2]

Okay...

The fetched row error is to warn you that you're not capturing all of the available data.  I think the default limit OOTB is 50,000, but you can raise or lower this within PA settings.  I don't think there is a considerable performance issue, but you'd be wise to scale it relative to the size of your dataset.

Personally, I tend to set my date + state conditioning at the Indicator Source level.  That segments the data in the way we most analyse it.  It is at the Indicator level where I then apply the more specific conditioning, ie: 'Priority = 1', 'Category = Hardware', 'Has Breached' etc.

Always worth thinking about how you slice and dice your data: set the most common layer at the Source level, and any tuning at the Indicator level.  It'll give you far less headaches 🙂

Thanks,

DJL