Realtime reporting

meher Jammula
Giga Contributor

Hi team,

I  want to understand the following items

- Does ServiceNow provide real-time reporting in their analytics?

- If yes, does this real-time reporting work for all the tables? or is it restricted to certain tables?

- if not, what's that syn time of the data in the service, not analytics?

-i.e. If a user creates a ticket in the tool, how much time would it take for the analytics module to reflect the data?

 

 

1 ACCEPTED SOLUTION

Further information:
A senior support engineer informs me that only a few of the largest customers are using read replicas. So unless your tables are running well into the millions of active records each, you are unlikely to have it.

 

Even if you do have read replicas, if you were experiencing reporting lags because of them, this would be an issue and Support would attempt to resolve it.

As far as we know, no other table than a read replica can even potentially exist as an intermediary between the report and the backend. And in any case, no lag is expected.

So tl;dr: The report refers to the same live fact table in the backend. 

Regarding historical data: 

There is no limit to the historical data in a report. The data that the report fetches depends on the conditions that you create. However, if you fetch 10 years of data and that is 5-10 millions of records and then you try to trend on it, that report will be very slow.

View solution in original post

7 REPLIES 7

meher,

Regarding your original question, a developer writes:

All the reporting queries are designed to go to read replica if [it] exists. With read replica, there could be a replication lag. Generally, the lag is less than 5 minutes.

If seeing the new number is critical then customer can use the record watcher functionality to update single score reports on the fly. This is almost immediate.
 
The only description I can find of a read replica is in a reply to a 6-year-old Community post:
https://community.servicenow.com/community?id=community_question&sys_id=971f83e1dbdcdbc01dcaf3231f961927
 
I've been talking to the devs and we know that read replica used to be a paid feature but we don't know if it still is. Anyway, can you find out if you have read replicas enabled on your instance? If not, I don't think there are any other "intermediate" tables that could potentially cause lags.

Further information:
A senior support engineer informs me that only a few of the largest customers are using read replicas. So unless your tables are running well into the millions of active records each, you are unlikely to have it.

 

Even if you do have read replicas, if you were experiencing reporting lags because of them, this would be an issue and Support would attempt to resolve it.

As far as we know, no other table than a read replica can even potentially exist as an intermediary between the report and the backend. And in any case, no lag is expected.

So tl;dr: The report refers to the same live fact table in the backend. 

Regarding historical data: 

There is no limit to the historical data in a report. The data that the report fetches depends on the conditions that you create. However, if you fetch 10 years of data and that is 5-10 millions of records and then you try to trend on it, that report will be very slow.

Amazing piece of information - Thanks for helping me jeffrubinoff