Track user updates over an incident

[rafael_merces2]

Hi all,

I've been reading some posts regarding sys_history_line, sys_history_set and even tried to do a database view on these tables (joining with incident table as well) but without success. Also it is not best pratices to run reports over system tables (sys_audit, for example).

The request here is this: The user wants to know everyone who updated an incident, even if the person was not set on 'assigned to'. Therefore I do not have the metrics for every update (someone can update a ticket just to include a comment).

What would be the best approach? Any suggestions?

Thanks,

[monicarazdan]

Hi Rafael,

You can use Live feed to do the following -

Follow a record feed from a list

Follow a record feed from a form

Follow other Live Feed users

Add Live Feed to your homepage

Follow feeds  

I hope this information is useful for you.

Thanks!

Monica

ServiceNow | Everything as a Service

Please hit Like/Helpful/Correct if applicable.

[Jon Barnes]

yes, sys_history_line and sys_history_set are not good tables to report on because they are generated dynamically and as needed.   The main issue with sys_audit is usually size, but they are indexed on document_key, so as long as you are reporting on only one incident at a time, you can query by document_key = incident sys_id and it will be fast.

However, if you are doing that approach, you may as well have them right click the header, and click History>List to see all the updates made to the incident.

Are your requirements different than this?

[rafael_merces2]

Thanks Jonathan and Monica.

Regarding your question Jonathan, they would like to know the number of incidents that a user has added a comment (which for us means that he worked on this incident).

Therefore it should be a query on more than one incident per time.

[Jon Barnes · Accepted solution]

for that you can use sys_audit or sys_journal_field, but as you said, it wouldn't be ideal to provide the customer a report on these tables, but if it is a one-off type of thing, you could provide it for them.   in either case, if this request is required often, you may want to add an index on the sys_created_by field on either of the tables as that will hold the user_name of the user that made the update...