Use PDIs? Take our 5-minute survey to help shape the PDI roadmap.

classify tasks agentic workflow field prediction logs

Deepika54
Tera Contributor

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

1 ACCEPTED SOLUTION

Abhishek Pal
Giga Guru

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

View solution in original post

1 REPLY 1

Abhishek Pal
Giga Guru

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