- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
hi experts,
We are using the OOB classify tasks agentic workflow to predict service,service offering,category,subcategory for incident records.
Is there any backend table in servicenow which stores the logs of which all fields the agentic workflow was able to predict for the incident record
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @Deepika54 ,
Yes, you can trace this, but there is an important distinction between:
1. Fields configured for prediction
2. Fields the AI actually predicted during a particular execution
3. Fields that were finally updated on the Incident
For the OOB Classify tasks agentic workflow, I would check the following.
1. Check which fields are configured for prediction
Navigate to:
Now Assist Skill Config [sn_nowassist_skill_config]
Open:
Task Classify Tasks Skill Config
Then open the related:
Field Predictor
configuration.
Check the:
Fields
variable.
This defines which fields the Classify tasks workflow is configured to predict.
For example:
service
service_offering
category
subcategory
So this gives you the configured list, but it does not tell you which fields were successfully predicted for one specific Incident execution.
2. Find the Agentic Workflow execution
Open:
sn_aia_execution_plan.list
Execution Plans [sn_aia_execution_plan] stores one execution of the agentic workflow.
Filter using values such as:
Agentic workflow = Classify tasks
and:
Created = required execution time
If your execution was associated with the Incident record through the trigger, also check the related record information.
Open the applicable execution.
3. Check Execution Tasks
From the Execution Plan, review:
Execution Tasks [sn_aia_execution_task]
This table contains the individual steps executed as part of the plan.
For Classify tasks, look for the task corresponding to the:
Record field value prediction AI agent
or the field-prediction/update tool used by that agent.
This tells you which step actually performed the prediction.
4. Check Tools Executions - this is the most useful table
Open:
sn_aia_tools_execution.list
Filter using the Execution Plan sys_id.
Tools Executions contains the actual tool executions performed by the agentic workflow.
For the Field Predictor execution, inspect the tool:
Input
Output
Status
Error information
The output is the best place to determine what the AI predicted for that specific execution.
Conceptually you may see information similar to:
service = <predicted service>
service_offering = <predicted offering>
category = Hardware
subcategory = Network
Therefore the trace is:
Incident
-> Classify tasks
-> sn_aia_execution_plan
-> sn_aia_execution_task
-> sn_aia_tools_execution
-> Tool output containing predicted values
I would use sn_aia_tools_execution rather than trying to find a separate Classify Tasks prediction-log table.
5. If you need to know what was actually updated on Incident
There is another important distinction:
Predicted value
does not always mean
field was successfully updated.
If you need an audit report of fields that were actually changed, use:
Sys Audit [sys_audit]
Filter:
Table name = incident
Document key = <Incident sys_id>
Created = around execution time
Then inspect:
Field name
Old value
New value
Updated by
This gives you the final persisted field changes.
So for example:
Field Predictor output:
category = Network
and:
sys_audit:
category
Old value = Hardware
New value = Network
confirms that the prediction was actually committed to the Incident.
ServiceNow also visually identifies fields changed by agentic AI on the record form with an AI-modified indicator.
6. If you need the deeper LLM trace
For deeper troubleshooting, ServiceNow also provides:
sn_aia_gen_ai_m2m
This maps:
sn_aia_execution_task
-> Generative AI log metadata
and can be used when you need to investigate the underlying GenAI invocation associated with an execution task.
I would not use the GenAI tables as the primary reporting source though.
For operational troubleshooting, use:
sn_aia_execution_plan
-> sn_aia_execution_task
-> sn_aia_tools_execution
7. Recommended reporting approach
If your requirement is to report something like:
Incident | Service predicted | Service Offering predicted | Category predicted | Subcategory predicted | Updated successfully
I would NOT report directly from the raw AI execution tables long term.
The execution logs are primarily runtime/troubleshooting records and their schema/retention is controlled by the AI Agent framework.
Instead, if this is a business audit requirement, create a small custom audit table such as:
u_incident_classification_audit
and capture:
Incident
Execution Plan
Field
Predicted Value
Previous Value
Final Value
Status
Timestamp
after the agentic workflow completes.
But first validate your requirement using the OOB execution tables.
So the short answer is:
Configured prediction fields
-> sn_nowassist_skill_config / Field Predictor configuration
Agentic workflow execution
-> sn_aia_execution_plan
Individual prediction step
-> sn_aia_execution_task
Actual prediction tool input/output
-> sn_aia_tools_execution
Final fields actually changed
-> sys_audit
For your exact question, I would start with:
sn_aia_tools_execution
for one Classify tasks Execution Plan.
Official ServiceNow references:
Classify tasks:
https://www.servicenow.com/docs/r/intelligent-experiences/classify-tasks.html
Now Assist AI Agent tables:
https://www.servicenow.com/docs/r/intelligent-experiences/na-aia-reference.html
Testing Agentic Workflow executions:
https://www.servicenow.com/docs/r/intelligent-experiences/test-aia-use-case.html
Sys Audit:
https://www.servicenow.com/docs/r/platform-security/c_UnderstandingTheSysAuditTable.html
Related ServiceNow Community reference for AI Agent execution/debugging:
https://www.servicenow.com/community/ceg-ai-coe-articles/a-field-guide-to-evaluating-analyzing-and-d...
Hope this helps!
If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.
Kind Regards,
Abhishek Pal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @Deepika54 ,
Yes, you can trace this, but there is an important distinction between:
1. Fields configured for prediction
2. Fields the AI actually predicted during a particular execution
3. Fields that were finally updated on the Incident
For the OOB Classify tasks agentic workflow, I would check the following.
1. Check which fields are configured for prediction
Navigate to:
Now Assist Skill Config [sn_nowassist_skill_config]
Open:
Task Classify Tasks Skill Config
Then open the related:
Field Predictor
configuration.
Check the:
Fields
variable.
This defines which fields the Classify tasks workflow is configured to predict.
For example:
service
service_offering
category
subcategory
So this gives you the configured list, but it does not tell you which fields were successfully predicted for one specific Incident execution.
2. Find the Agentic Workflow execution
Open:
sn_aia_execution_plan.list
Execution Plans [sn_aia_execution_plan] stores one execution of the agentic workflow.
Filter using values such as:
Agentic workflow = Classify tasks
and:
Created = required execution time
If your execution was associated with the Incident record through the trigger, also check the related record information.
Open the applicable execution.
3. Check Execution Tasks
From the Execution Plan, review:
Execution Tasks [sn_aia_execution_task]
This table contains the individual steps executed as part of the plan.
For Classify tasks, look for the task corresponding to the:
Record field value prediction AI agent
or the field-prediction/update tool used by that agent.
This tells you which step actually performed the prediction.
4. Check Tools Executions - this is the most useful table
Open:
sn_aia_tools_execution.list
Filter using the Execution Plan sys_id.
Tools Executions contains the actual tool executions performed by the agentic workflow.
For the Field Predictor execution, inspect the tool:
Input
Output
Status
Error information
The output is the best place to determine what the AI predicted for that specific execution.
Conceptually you may see information similar to:
service = <predicted service>
service_offering = <predicted offering>
category = Hardware
subcategory = Network
Therefore the trace is:
Incident
-> Classify tasks
-> sn_aia_execution_plan
-> sn_aia_execution_task
-> sn_aia_tools_execution
-> Tool output containing predicted values
I would use sn_aia_tools_execution rather than trying to find a separate Classify Tasks prediction-log table.
5. If you need to know what was actually updated on Incident
There is another important distinction:
Predicted value
does not always mean
field was successfully updated.
If you need an audit report of fields that were actually changed, use:
Sys Audit [sys_audit]
Filter:
Table name = incident
Document key = <Incident sys_id>
Created = around execution time
Then inspect:
Field name
Old value
New value
Updated by
This gives you the final persisted field changes.
So for example:
Field Predictor output:
category = Network
and:
sys_audit:
category
Old value = Hardware
New value = Network
confirms that the prediction was actually committed to the Incident.
ServiceNow also visually identifies fields changed by agentic AI on the record form with an AI-modified indicator.
6. If you need the deeper LLM trace
For deeper troubleshooting, ServiceNow also provides:
sn_aia_gen_ai_m2m
This maps:
sn_aia_execution_task
-> Generative AI log metadata
and can be used when you need to investigate the underlying GenAI invocation associated with an execution task.
I would not use the GenAI tables as the primary reporting source though.
For operational troubleshooting, use:
sn_aia_execution_plan
-> sn_aia_execution_task
-> sn_aia_tools_execution
7. Recommended reporting approach
If your requirement is to report something like:
Incident | Service predicted | Service Offering predicted | Category predicted | Subcategory predicted | Updated successfully
I would NOT report directly from the raw AI execution tables long term.
The execution logs are primarily runtime/troubleshooting records and their schema/retention is controlled by the AI Agent framework.
Instead, if this is a business audit requirement, create a small custom audit table such as:
u_incident_classification_audit
and capture:
Incident
Execution Plan
Field
Predicted Value
Previous Value
Final Value
Status
Timestamp
after the agentic workflow completes.
But first validate your requirement using the OOB execution tables.
So the short answer is:
Configured prediction fields
-> sn_nowassist_skill_config / Field Predictor configuration
Agentic workflow execution
-> sn_aia_execution_plan
Individual prediction step
-> sn_aia_execution_task
Actual prediction tool input/output
-> sn_aia_tools_execution
Final fields actually changed
-> sys_audit
For your exact question, I would start with:
sn_aia_tools_execution
for one Classify tasks Execution Plan.
Official ServiceNow references:
Classify tasks:
https://www.servicenow.com/docs/r/intelligent-experiences/classify-tasks.html
Now Assist AI Agent tables:
https://www.servicenow.com/docs/r/intelligent-experiences/na-aia-reference.html
Testing Agentic Workflow executions:
https://www.servicenow.com/docs/r/intelligent-experiences/test-aia-use-case.html
Sys Audit:
https://www.servicenow.com/docs/r/platform-security/c_UnderstandingTheSysAuditTable.html
Related ServiceNow Community reference for AI Agent execution/debugging:
https://www.servicenow.com/community/ceg-ai-coe-articles/a-field-guide-to-evaluating-analyzing-and-d...
Hope this helps!
If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.
Kind Regards,
Abhishek Pal