Key Tables Used in ServiceNow Agentic AI (Development, Migration, and Troubleshooting)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday - last edited yesterday
When working with ServiceNow Agentic AI, understanding the underlying system tables is essential for configuring agents, validating deployments, and troubleshooting issues.
The following tables are the core components for Agentic AI orchestration, execution, and Generative AI tracking.
1. Core Agent Tables
These tables are used to define the agents, their settings, and the tools they can utilize.
| Category | Table Name | Purpose | Critical Usage Context |
| Configuration | sn_aia_agent | Stores the core definitions of AI Agents. | Migration: specific table to check when validating if an agent exists across environments. |
| Configuration | sn_aia_agent_config | Stores configuration details, including activation states. | Dev & Validation: Use this to verify if an agent is currently active and properly configured. |
| Tools | sn_aia_agent_tool_m2m | Manages the many-to-many relationship between Agents and Tools. | Migration: Essential to verify that agents haven't lost their tool associations during transfer. |
| Use Cases | sn_aia_usecase | Defines the specific use cases supported by Agentic AI. | Deployment: Validates that use cases are correctly mapped to the right agents. |
2. Orchestration & Teams
These tables control how agents work together and how flows are triggered.
| Category | Table Name | Purpose | Critical Usage Context |
| Teams | sn_aia_team | Defines Agentic AI teams (groups of agents). | Migration: Validates that team-level structures are intact. |
| Teams | sn_aia_team_member | Stores individual agent membership within a team. | Troubleshooting: Confirms which agents are participating in a specific team's workflow. |
| Flow Logic | sn_aia_trigger_configuration | Stores the trigger configurations for Agentic Flows. | Troubleshooting: Critical for checking why an agent execution did (or did not) start. |
3. Runtime & Execution Tracking
These tables are your primary sources for debugging live interactions.
| Category | Table Name | Purpose | Critical Usage Context |
| Execution | sn_aia_execution_plan | Stores the high-level plan generated for a request. | Troubleshooting: The first place to look to see if the system acknowledged the request and formed a plan. |
| Execution | sn_aia_execution_task | Stores the specific tasks/steps inside a plan. | Debugging: Use this to find exactly which step failed or stalled within a conversation. |
| GenAI Logs | sys_gen_ai_usage_log | Captures high-level GenAI usage events platform-wide. | Monitoring: Confirms that the LLM was actually invoked during the agent's execution. |
| GenAI Logs | sys_gen_ai_log_metadata | Stores detailed metadata (token counts, response headers). | Auditing: Used for deep-dive analysis of AI costs and response latency. |
Quick Reference: Tables by Lifecycle Phase
Use this checklist to know which tables to query during different stages of your project.
Phase 1: Development
Focus: Configuration & Connections.
Check: sn_aia_agent_config, sn_aia_agent_tool_m2m, sn_aia_usecase.
Phase 2: Migration & Deployment
Focus: Integrity & Completeness.
Check: sn_aia_agent (existence), sn_aia_team (structure), sn_aia_trigger_configuration (triggers).
Phase 3: Troubleshooting
Focus: Runtime Errors & Logs.
Check: sn_aia_execution_plan (did it start?), sn_aia_execution_task (where did it stop?), sys_gen_ai_usage_log (did the AI respond?).
If you found this post helpful, please mark it as helpful!
