The Zurich release has arrived! Interested in new features and functionalities? Click here for more

Form field update

ayush_g
Tera Contributor

How to check if any form field is getting updated by integration or discovery or is it manually updated

1 ACCEPTED SOLUTION

Hi @ayush_g ,

 

you can use the audit for that

if your table has audit enabled

you open the record and check like this

ChaitanyaILCR_0-1750945927785.png

 

filter your field name you want to check and sort using updated time

ChaitanyaILCR_1-1750945979163.png

 

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya

 

View solution in original post

5 REPLIES 5

Chaitanya ILCR
Mega Patron

Hi @ayush_g 

 

if the auditing is enabled you can check the history of the record 

 

Configuring auditing for a table 

 

https://www.youtube.com/watch?v=-fhqpBkK7As

 

 

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya

Hi @chaitanya,

 

we need to identify that how it got filled first time.

 

Thanks

Hi @ayush_g ,

 

you can use the audit for that

if your table has audit enabled

you open the record and check like this

ChaitanyaILCR_0-1750945927785.png

 

filter your field name you want to check and sort using updated time

ChaitanyaILCR_1-1750945979163.png

 

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya

 

Selva Arun
Mega Sage
Mega Sage

Hi @ayush_g,

 

That's an excellent question that is fundamental to maintaining a healthy and trustworthy ServiceNow instance. Chaitanya's answer is correct—auditing is the first and most important step. However, to truly determine the source of the update (Manual vs. Integration vs. Discovery), we need to combine auditing with other diagnostic tools.

 

Here is a comprehensive, multi-layered approach to get a definitive answer.

Method 1: Auditing & Record History (The 'What' and 'Who')

This is your starting point. It tells you WHAT field changed, its old and new values, and WHO the system logged as the user.

 

Ensure Auditing is Enabled: Navigate to System Definition > Dictionary and find the record for your table (e.g., cmdb_ci_computer). Ensure the 'Audit' checkbox is checked. If not, auditing will not be captured going forward.

View the Record History: On the form for the specific record you are investigating, right-click the form header and choose History > List. This will show you a detailed, field-by-field audit log.

 

Interpret the 'Updated by' Field: This is the crucial clue:

If Updated by is a person's name (e.g., 'john.doe'): This was a manual update made by a logged-in user through the standard form.
If Updated by is an integration account (e.g., 'servicenow.integration'): This was an automated update from a REST/SOAP integration.
If Updated by is 'system': This is an ambiguous but important clue. It means the update was performed by a server-side process, which could be Discovery, a Scheduled Job, an Import Set, or a Business Rule.

 

Limitation: Auditing is excellent, but 'system' updates require a deeper dive to find the true source.

 

Method 2: Transaction Logs (The 'How' and 'Where')

If the audit log shows the user as 'system', the Transaction Log is your next best tool. It tells you HOW the system was accessed.

 

Navigate to Transaction Logs: Go to System Logs > Transactions (All Users).

Filter the Logs: Filter the list for the timeframe of the update. The most useful filter is 'Created on' (around the time of the update) and 'Created by' = system.

Examine the 'URL' Column: The URL tells you what kind of process initiated the update:

Discovery: The URL might contain /api/now/probe or look like an API call processed by a MID Server.
Import Set / Integration: The URL will often be the name of the Scheduled Job that triggered the import (e.g., LANDesk - Computers).


Business Rule: The URL will be the transaction that triggered the business rule. For example, if another user updated a related record, you might see that record's URL, and know a business rule cascaded the update.


Method 3: Source-Specific Logs (The Definitive Proof)

For automated updates, you can go directly to the source's own logs for definitive proof.

 

To Confirm a Discovery Update:

 

Navigate to the ECC Queue (Discovery > ECC Queue).
Filter for the timeframe and look for 'Input' records with a 'State' of 'processed'. The XML payload will contain the exact data that Discovery sent to the instance to be processed by sensors.

 

To Confirm an Import Set Update:

 

Navigate to the Import Set Runs module for your data source (e.g., System Import Sets > Import Set Runs).
Find the import run that corresponds to the update time.


Open the record and look at the 'Transform History'. This will show you the exact source record that was transformed and applied to your target record.


Summary: A Quick Reference Table

Use this table to quickly identify the source based on the evidence you find.

Update Source Key Evidence / Telltale Sign Where to Look First
Manual Update 'Updated by' is a real user's name. Record History (Audit)
Integration (REST/SOAP) 'Updated by' is a service account; URL in transaction log is /api/.... Record History, Transaction Logs
Integration (Import Set) 'Updated by' is 'system'; URL is a scheduled job name. Record History, Import Set Runs
Discovery 'Updated by' is 'system'; correlated ECC Queue 'input' records exist. Record History, ECC Queue

 

Hope this comprehensive guide helps you solve not just this issue, but many more in the future!

 

If you believe the solution provided has adequately addressed your query, could you please **mark it as 'Helpful'** and **'Accept it as a Solution'**? This will help other community members who might have the same question find the answer more easily.

 

Thank you for your consideration.

Selva Arun