# ServiceNow table reference: tables and key fields

Source: The Snowball (https://thesnowball.co/table). 74 tables, 1152 key fields. Records last updated 2026-03-09; file generated 2026-09-30.

Key fields are the columns The Snowball documents for each table, not every column on the table. Written and maintained by The Snowball, not by ServiceNow. Behaviour can change between releases; confirm against the official ServiceNow API reference for your release (https://developer.servicenow.com/dev.do#!/reference).

Free to quote and reuse with attribution (CC BY 4.0): name "The Snowball" and link the page you used (for example https://thesnowball.co/servicenow-tables.md).

## Tables

| Table | Label | Module | Key fields | Page |
|---|---|---|---|---|
| change_request | Change Request | ITSM | 20 | https://thesnowball.co/table/change_request |
| cmdb_ci | Configuration Item | CMDB | 19 | https://thesnowball.co/table/cmdb_ci |
| cmdb_ci_appl | Application | CMDB | 19 | https://thesnowball.co/table/cmdb_ci_appl |
| cmdb_ci_database | Database | CMDB | 20 | https://thesnowball.co/table/cmdb_ci_database |
| cmdb_ci_server | Server | CMDB | 21 | https://thesnowball.co/table/cmdb_ci_server |
| cmdb_ci_service | Business Service | CMDB | 18 | https://thesnowball.co/table/cmdb_ci_service |
| cmdb_rel_ci | CI Relationship | CMDB | 7 | https://thesnowball.co/table/cmdb_rel_ci |
| cmn_rota | On-call Rota | ITSM | 16 | https://thesnowball.co/table/cmn_rota |
| cmn_schedule | Schedule | Platform | 8 | https://thesnowball.co/table/cmn_schedule |
| contract_sla | SLA Definition | ITSM | 16 | https://thesnowball.co/table/contract_sla |
| ecc_queue | ECC Queue | Platform | 14 | https://thesnowball.co/table/ecc_queue |
| incident | Incident | ITSM | 21 | https://thesnowball.co/table/incident |
| item_option_new | Catalog Variable | Service Catalog | 17 | https://thesnowball.co/table/item_option_new |
| item_option_new_set | Variable Set | Service Catalog | 16 | https://thesnowball.co/table/item_option_new_set |
| kb_category | Knowledge Category | Knowledge | 15 | https://thesnowball.co/table/kb_category |
| kb_knowledge | Knowledge Article | Knowledge | 19 | https://thesnowball.co/table/kb_knowledge |
| kb_knowledge_base | Knowledge Base | Knowledge | 18 | https://thesnowball.co/table/kb_knowledge_base |
| live_group_profile | Collaboration Group | Collaboration | 19 | https://thesnowball.co/table/live_group_profile |
| pa_indicators | Indicator | Performance Analytics | 15 | https://thesnowball.co/table/pa_indicators |
| pa_scores | Score | Performance Analytics | 18 | https://thesnowball.co/table/pa_scores |
| problem | Problem | ITSM | 20 | https://thesnowball.co/table/problem |
| sc_cat_item | Catalog Item | Service Catalog | 20 | https://thesnowball.co/table/sc_cat_item |
| sc_category | Catalog Category | Service Catalog | 19 | https://thesnowball.co/table/sc_category |
| sc_item_option | Catalog Item Option | Service Catalog | 9 | https://thesnowball.co/table/sc_item_option |
| sc_req_item | Requested Item (RITM) | Service Catalog | 16 | https://thesnowball.co/table/sc_req_item |
| sc_request | Service Catalog Request | Service Catalog | 18 | https://thesnowball.co/table/sc_request |
| sc_task | Catalog Task | Service Catalog | 20 | https://thesnowball.co/table/sc_task |
| sn_customerservice_case | Customer Case | CSM | 17 | https://thesnowball.co/table/sn_customerservice_case |
| sn_si_incident | Security Incident | SecOps | 18 | https://thesnowball.co/table/sn_si_incident |
| sn_vul_vulnerable_item | Vulnerable Item | SecOps | 15 | https://thesnowball.co/table/sn_vul_vulnerable_item |
| sp_page | Portal Page | Service Portal | 15 | https://thesnowball.co/table/sp_page |
| sp_widget | Widget | Service Portal | 18 | https://thesnowball.co/table/sp_widget |
| sys_atf_test | ATF Test | Development | 15 | https://thesnowball.co/table/sys_atf_test |
| sys_atf_test_suite | ATF Test Suite | Development | 16 | https://thesnowball.co/table/sys_atf_test_suite |
| sys_attachment | Attachment | Platform | 10 | https://thesnowball.co/table/sys_attachment |
| sys_attachment_doc | Attachment Document | Platform | 5 | https://thesnowball.co/table/sys_attachment_doc |
| sys_choice | Choice | Platform | 10 | https://thesnowball.co/table/sys_choice |
| sys_db_object | Table | Platform | 14 | https://thesnowball.co/table/sys_db_object |
| sys_dictionary | System Dictionary | Platform | 18 | https://thesnowball.co/table/sys_dictionary |
| sys_email | Email Log | Platform | 20 | https://thesnowball.co/table/sys_email |
| sys_hub_action_type_base | Action | Flow Designer | 16 | https://thesnowball.co/table/sys_hub_action_type_base |
| sys_hub_flow | Flow | Flow Designer | 15 | https://thesnowball.co/table/sys_hub_flow |
| sys_hub_subflow | Subflow | Flow Designer | 15 | https://thesnowball.co/table/sys_hub_subflow |
| sys_import_set | Import Set | Integration | 17 | https://thesnowball.co/table/sys_import_set |
| sys_notification | Notification | Platform | 19 | https://thesnowball.co/table/sys_notification |
| sys_portal | Service Portal | Service Portal | 14 | https://thesnowball.co/table/sys_portal |
| sys_properties | System Property | Platform | 11 | https://thesnowball.co/table/sys_properties |
| sys_report | Report | Reporting | 15 | https://thesnowball.co/table/sys_report |
| sys_rest_message | REST Message | Integration | 15 | https://thesnowball.co/table/sys_rest_message |
| sys_script | Business Rule | Development | 19 | https://thesnowball.co/table/sys_script |
| sys_script_client | Client Script | Development | 15 | https://thesnowball.co/table/sys_script_client |
| sys_script_include | Script Include | Development | 11 | https://thesnowball.co/table/sys_script_include |
| sys_transform_entry | Field Map | Integration | 12 | https://thesnowball.co/table/sys_transform_entry |
| sys_transform_map | Transform Map | Integration | 14 | https://thesnowball.co/table/sys_transform_map |
| sys_trigger | Scheduled Job | Platform | 18 | https://thesnowball.co/table/sys_trigger |
| sys_ui_action | UI Action | Development | 19 | https://thesnowball.co/table/sys_ui_action |
| sys_ui_policy | UI Policy | Development | 16 | https://thesnowball.co/table/sys_ui_policy |
| sys_update_set | Update Set | Development | 12 | https://thesnowball.co/table/sys_update_set |
| sys_update_xml | Update Set Entry | Development | 14 | https://thesnowball.co/table/sys_update_xml |
| sys_user | User | Platform | 18 | https://thesnowball.co/table/sys_user |
| sys_user_grmember | Group Member | Platform | 4 | https://thesnowball.co/table/sys_user_grmember |
| sys_user_group | Group | Platform | 13 | https://thesnowball.co/table/sys_user_group |
| sys_user_has_role | User Role | Platform | 7 | https://thesnowball.co/table/sys_user_has_role |
| sys_user_role | Role | Platform | 11 | https://thesnowball.co/table/sys_user_role |
| sys_ws_definition | Scripted REST Service | Integration | 15 | https://thesnowball.co/table/sys_ws_definition |
| sysapproval_approver | Approval | Platform | 15 | https://thesnowball.co/table/sysapproval_approver |
| sysauto_script | Scheduled Script Execution | Platform | 15 | https://thesnowball.co/table/sysauto_script |
| sysevent | System Event | Platform | 15 | https://thesnowball.co/table/sysevent |
| syslog | System Log Entry | Platform | 15 | https://thesnowball.co/table/syslog |
| task | Task | Platform | 20 | https://thesnowball.co/table/task |
| task_sla | Task SLA | ITSM | 16 | https://thesnowball.co/table/task_sla |
| ua_task | HR Case | HRSD | 20 | https://thesnowball.co/table/ua_task |
| wf_context | Workflow Context | Workflow | 15 | https://thesnowball.co/table/wf_context |
| wf_workflow | Workflow | Workflow | 17 | https://thesnowball.co/table/wf_workflow |

## change_request (Change Request)

The change_request table stores controlled changes to IT infrastructure and services within the ITSM module. Extends the task table with three distinct change types (Normal, Emergency, Standard) that follow different approval workflows. Key gotcha: the state field uses different values than incident, and change types determine which fields are required.

| Field | Label | Type | Notes |
|---|---|---|---|
| type | Type | choice | Defines change type: normal, emergency, standard, model. Controls approval workflows, required fields, and business rule behavior - changing this mid-process can bypass approvals. |
| state | State | integer | Current change state using different values than other task tables: -5 (New), -4 (Assess), -3 (Authorize), -2 (Scheduled), -1 (Implement), 0 (Review), 3 (Closed). |
| approval | Approval | choice | Overall approval status: not requested, requested, approved, rejected, cancelled. Calculated from sysapproval_approver records, not directly settable in most cases. |
| risk | Risk | integer | Risk assessment: 1 (High), 2 (Moderate), 3 (Low), 4 (Planning). Often auto-calculated based on affected CIs and implementation window, drives CAB requirements. |
| priority | Priority | integer | Change priority: 1 (Critical), 2 (High), 3 (Moderate), 4 (Low), 5 (Planning). Unlike incident priority, not auto-calculated from impact/urgency matrix. |
| category | Category | choice | Change category like Software, Hardware, Network, Documentation. Used for approval routing and metrics reporting - required for most change types. |
| requested_by | Requested by | reference | User who requested the change (references sys_user). Different from caller_id in task table - represents business requestor, not technical implementer. |
| change_manager | Change manager | reference | User responsible for managing the change process (references sys_user). Has special ACL permissions and approval authority for the change. |
| implementation_plan | Implementation plan | string | Detailed steps for implementing the change. Required for Normal changes before approval, often enforced by business rules based on change type. |
| backout_plan | Backout plan | string | Steps to reverse the change if it fails. Required for most change types and commonly validated by approval workflows before implementation. |
| test_plan | Test plan | string | Testing procedures to verify change success. Required for Normal changes in most configurations, validated during Review state. |
| planned_start_date | Planned start date | glide_date_time | When implementation begins. Heavily indexed and queried for conflict detection and calendar views - always use date ranges in queries for performance. |
| planned_end_date | Planned end date | glide_date_time | When implementation should complete. Used with start date for maintenance window calculations and resource scheduling. |
| cab_required | CAB required | boolean | Whether change advisory board approval is needed. Usually calculated based on risk and type, not directly settable - driven by business rules. |
| cab_date | CAB date | glide_date_time | When CAB will review the change. Set automatically when cab_required is true, used for meeting scheduling and approval workflows. |
| conflict_status | Conflict status | choice | Indicates scheduling conflicts with other changes: Not Run, Conflict, No Conflict. Auto-calculated by scheduled jobs, manual updates get overwritten. |
| std_change_producer_version | Standard change template version | reference | Links to standard change template (references std_change_producer_version). Required for Standard changes to work properly - without it behaves like Normal change. |
| review_status | Review status | integer | Post-implementation review outcome: 4 (Successful), 3 (Successful with issues), 2 (Unsuccessful), 1 (Yet to be reviewed). Used for change success metrics. |
| reason | Reason | choice | Business justification: Availability, Compliance, Expansion, Improvement, Maintenance, Other. Required field that drives approval routing in many implementations. |
| justification | Justification | string | Detailed business justification for the change. Often required for approval workflows and used in CAB review processes for Normal changes. |

Page: https://thesnowball.co/table/change_request

## cmdb_ci (Configuration Item)

The cmdb_ci table is the foundation of ServiceNow's Configuration Management Database, storing all Configuration Items across your IT infrastructure. Owned by the CMDB module, it's extended by over 100 specialized CI classes. Never query this table directly in production — always target the specific CI class you need or use the cmdb table for cross-class queries.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Display name of the CI. Not guaranteed to be unique across CI classes — use sys_id for reliable identification. |
| operational_status | Operational Status | integer | Current operational state (1=Operational, 2=Non-Operational, etc.). Stores integer values, not choice labels. |
| install_status | Install Status | integer | Lifecycle stage of the CI (1=Installed, 6=Retired, etc.). Often confused with operational_status but represents different concepts. |
| sys_class_name | Class | string | The exact table name of the CI's class (cmdb_ci_server, cmdb_ci_appl, etc.). Essential for performance when querying CI hierarchies. |
| support_group | Support Group | reference | Group responsible for supporting this CI. References sys_user_group but doesn't automatically inherit from parent CIs. |
| assignment_group | Assignment Group | reference | Group assigned to manage this CI. Separate from support_group and used for task assignment propagation. |
| owned_by | Owned by | reference | Business owner of the CI. References sys_user and affects approval routing for CI-related changes. |
| managed_by | Managed by | reference | Technical manager responsible for the CI. Often different from owned_by and used for operational notifications. |
| company | Company | reference | Company that owns the CI. May be null for discovered CIs — always null-check before using in filters. |
| location | Location | reference | Physical or logical location of the CI. References cmn_location and enables geographic reporting. |
| environment | Environment | string | Deployment environment (Production, Test, Development). Critical for change impact analysis and approval workflows. |
| asset_tag | Asset Tag | string | Physical asset identifier linking CI to asset management records. Used for hardware lifecycle tracking. |
| serial_number | Serial Number | string | Manufacturer serial number. Key field for hardware CI identification and warranty tracking. |
| model_id | Model | reference | References cmdb_model table for hardware specifications. Essential for capacity planning and compatibility checks. |
| manufacturer | Manufacturer | reference | References core_company for the CI manufacturer. Used in vendor management and support routing. |
| discovery_source | Discovery Source | string | How the CI was discovered (ServiceNow Discovery, Import, Manual). Affects data quality scoring and update policies. |
| first_discovered | First Discovered | glide_date_time | When CI was first found by discovery. Read-only field used for CMDB age analysis and lifecycle reporting. |
| last_discovered | Last Discovered | glide_date_time | Most recent discovery timestamp. Used to identify stale CIs that may need retirement. |
| attributes | Attributes | string | JSON field storing discovery attributes. Contains key-value pairs from discovery probes — parse carefully to avoid errors. |

Page: https://thesnowball.co/table/cmdb_ci

## cmdb_ci_appl (Application)

The cmdb_ci_appl table stores Application Configuration Items in ServiceNow's CMDB module, extending cmdb_ci. Before querying, know that most application CIs are linked to business services and have complex relationship hierarchies that require careful navigation.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | The display name of the application. Often used as a natural key for lookups, but not guaranteed unique across environments. |
| operational_status | Operational status | choice | Current operational state inherited from cmdb_ci. Choice values vary by organization but typically include 'Operational', 'Non-Operational', 'Repair in Progress'. |
| business_criticality | Business criticality | choice | Business impact level for prioritization and SLA assignment. Commonly empty on creation despite being crucial for impact analysis. |
| version | Version | string | Application version string with no format enforcement. Contains everything from semantic versions to build timestamps and branch names. |
| used_for | Used for | choice | Purpose classification like 'Production', 'Development', 'Testing'. Choice list often customized, making cross-environment scripts fragile. |
| support_group | Support group | reference | Reference to sys_user_group for application support assignment. Inherited from cmdb_ci and heavily used in incident routing workflows. |
| owned_by | Owned by | reference | Reference to sys_user identifying the application owner or business stakeholder responsible for the application. |
| managed_by | Managed by | reference | Reference to sys_user for technical manager or application administrator. Often differs from owned_by in enterprise environments. |
| install_status | Install status | choice | Deployment status inherited from cmdb_ci. Values like 'Installed', 'Retired', 'Implementing' track application lifecycle state. |
| environment | Environment | string | Free-text environment descriptor like 'Production', 'Staging', 'Development'. No validation means inconsistent data entry. |
| short_description | Short description | string | Brief application description displayed in lists and reference fields. Inherited from cmdb_ci with 160-character limit. |
| description | Description | string | Detailed application description with HTML support. Used for comprehensive application documentation and service catalog entries. |
| company | Company | reference | Reference to core_company for multi-tenant environments. Affects domain separation and determines access scope in MSP setups. |
| location | Location | reference | Reference to cmn_location for physical or logical placement. Important for compliance reporting and geographical service delivery. |
| cost_center | Cost center | reference | Reference to cmn_cost_center for financial tracking and chargeback calculations. Links applications to budget and expense allocation. |
| vendor | Vendor | reference | Reference to core_company identifying the software vendor. Crucial for license management and vendor relationship tracking. |
| dns_domain | DNS Domain | string | Domain name for web applications and services. Used by Discovery and Service Mapping for automated dependency detection. |
| tcp_port | TCP Port | integer | Primary TCP port number for network services. Discovery uses this for application identification and connectivity testing. |
| skip_sync | Skip sync | boolean | Boolean flag to exclude from automated discovery and synchronization processes. Set to prevent Discovery from overwriting manual changes. |

Page: https://thesnowball.co/table/cmdb_ci_appl

## cmdb_ci_database (Database)

The `cmdb_ci_database` table stores database configuration items in the CMDB module. It extends `cmdb_ci` and represents database instances discovered through ITOM or manually created. Before querying, understand that database CIs are often clustered and may have complex parent-child relationships through hosting connections.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Database instance name, often including cluster ID or environment suffix from discovery tools. |
| operational_status | Operational Status | choice | Current operational state (Operational, Non-Operational, etc.). Discovery tools may update this independently from install_status. |
| install_status | Install Status | choice | Installation state of the database software. Can be inconsistent with operational_status when discovery runs fail. |
| environment | Environment | choice | Environment classification (Production, Test, Development). Critical for change approval workflows and access controls. |
| version | Version | string | Database version string. Not version-aware for comparisons - use custom logic for version sorting. |
| edition | Edition | string | Database edition (Enterprise, Standard, Express). Values vary by discovery tool requiring normalization. |
| tcp_port | TCP Port | string | Listening port numbers, often comma-separated for clustered instances. Use contains() for port matching. |
| is_clustered | Clustered | boolean | Indicates if database is part of a cluster. Affects dependency mapping and change impact analysis. |
| cluster_node_type | Cluster Node Type | choice | Role within cluster (Primary, Secondary, Witness). Empty for non-clustered instances. |
| database_type | Database Type | choice | Database platform (Oracle, SQL Server, MySQL, PostgreSQL). Used for specialized CI subclass routing. |
| run_as_user | Run As User | string | Operating system service account, not a ServiceNow user reference. Contains domain\username format. |
| startup_type | Startup Type | choice | Service startup configuration (Automatic, Manual, Disabled). Populated by Windows discovery primarily. |
| data_volume_gb | Data Volume (GB) | decimal | Total database size in gigabytes. Updated by discovery scans for capacity planning reports. |
| log_volume_gb | Log Volume (GB) | decimal | Transaction log size in gigabytes. Critical for backup and recovery planning automation. |
| max_db_size_gb | Max Database Size (GB) | decimal | Maximum configured database size. Used in capacity alerting and growth projection scripts. |
| collation | Collation | string | Database collation setting. Important for application compatibility and migration planning. |
| recovery_model | Recovery Model | choice | Backup recovery model (Full, Simple, Bulk). SQL Server specific field affecting backup strategies. |
| last_discovered | Last Discovered | glide_date_time | Timestamp of most recent discovery update. Use for CMDB health monitoring and stale data cleanup. |
| support_group | Support Group | reference | Reference to sys_user_group responsible for database support. Drives incident assignment automation. |
| owned_by | Owned by | reference | Reference to sys_user who owns the database CI. Used for access requests and change approvals. |

Page: https://thesnowball.co/table/cmdb_ci_database

## cmdb_ci_server (Server)

The cmdb_ci_server table stores Configuration Items representing physical and virtual servers in your CMDB. Owned by the CMDB module, it extends cmdb_ci and requires understanding of CI state management and discovery relationships before querying effectively.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Primary identifier for the server, typically the hostname. Must be unique and is used extensively in discovery correlation and relationship mapping. |
| host_name | Host name | string | The network hostname without domain. Discovery populates this from OS hostname commands, and it may differ from the Name field in virtualized environments. |
| dns_domain | DNS Domain | string | The DNS domain suffix for this server. Combined with host_name to create FQDN for network operations and monitoring integrations. |
| ip_address | IP Address | string | Primary management IP address for the server. May not reflect all network interfaces — use cmdb_rel_ci relationships to network adapters for complete IP inventory. |
| operational_status | Operational status | choice | Current operational state (1=Operational, 2=Non-Operational, etc.). Set by discovery but can become stale if discovery fails — not real-time server status. |
| install_status | Install Status | integer | Lifecycle status using numeric values (1=Installed, 6=Retired, 7=Stolen). Critical for asset management queries but often confused with operational_status. |
| os | Operating System | string | Operating system name and version detected by discovery. Format varies by discovery source and may require normalization for reporting consistency. |
| os_version | OS Version | string | Detailed OS version information including patch levels. Essential for compliance reporting but format inconsistencies require careful parsing in scripts. |
| cpu_count | CPU count | integer | Number of CPU cores detected by discovery. For virtual machines, this reflects allocated vCPUs rather than physical CPU cores on the host. |
| cpu_speed | CPU speed (MHz) | integer | CPU speed in MHz as reported by the operating system. May show virtualized values for VMs that don't reflect actual physical CPU specifications. |
| memory | RAM (MB) | integer | Total system memory in megabytes. Discovery reports available memory to OS, which may be less than physical RAM due to hardware reservations. |
| disk_space | Disk space (GB) | float | Total disk storage in gigabytes across all drives. Represents capacity, not usage — use storage device relationships for detailed disk utilization data. |
| classification | Classification | choice | CI classification (Production, Development, Test, etc.). Critical for change management approval workflows and incident prioritization rules. |
| environment | Environment | choice | Deployment environment designation. Often drives automated assignment rules and change approval processes, so must be accurately maintained. |
| location | Location | reference | Reference to cmn_location table for physical or logical placement. Used extensively in incident assignment and disaster recovery planning workflows. |
| support_group | Support group | reference | Reference to sys_user_group for the team responsible for this server. Primary driver for automated incident assignment and change approval routing. |
| owned_by | Owned by | reference | Reference to sys_user table for the business or technical owner. Used in approval workflows and accountability tracking for changes. |
| managed_by | Managed by | reference | Reference to sys_user table for day-to-day management responsibility. Often differs from owned_by and drives operational notifications. |
| correlation_id | Correlation ID | string | Auto-generated unique identifier used by Discovery for duplicate detection and CI correlation. Never modify manually or discovery updates will fail. |
| last_discovered | Last discovered | glide_date_time | Timestamp of most recent successful discovery scan. Essential for data freshness validation — stale data older than discovery schedule indicates issues. |
| virtual | Virtual | boolean | Indicates if this is a virtual machine rather than physical hardware. Affects capacity planning calculations and licensing compliance reporting. |

Page: https://thesnowball.co/table/cmdb_ci_server

## cmdb_ci_service (Business Service)

The cmdb_ci_service table stores business service configuration items that represent high-level business capabilities in the CMDB module. This table extends cmdb_ci and sits at the top of the CSDM hierarchy, making it critical for impact analysis and service mapping workflows.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Business service name like 'Customer Portal' or 'Payroll Processing'. Must be unique and is the primary identifier used in reports and dashboards. |
| operational_status | Operational status | choice | Current operational state. Unlike infrastructure CIs, this is manually managed and doesn't auto-update based on dependent component failures. |
| business_criticality | Business criticality | choice | Business impact level using values like 'Mission Critical', 'High', 'Medium', 'Low'. Different choice values than infrastructure CIs which use numbered priorities. |
| service_owner | Service owner | reference | References sys_user for the primary service manager. Can point to deactivated users, breaking notification workflows if not validated. |
| business_owner | Business owner | reference | References sys_user for the business stakeholder responsible for service outcomes. Often different from the technical service owner. |
| used_for | Used for | choice | Service purpose/classification like 'Production', 'Development', 'Testing'. Heavily customized per instance so values vary across environments. |
| install_status | Install status | choice | Lifecycle state inherited from cmdb_ci. Business services typically stay 'Installed' throughout their lifecycle unlike infrastructure components. |
| service_classification | Service classification | choice | Service type classification. Often empty on business services even though required on technical services - many orgs don't classify business services. |
| short_description | Short description | string | Brief service description displayed in lists and reports. Critical for business stakeholder understanding since technical details are irrelevant. |
| version | Version | string | Service version number. Unlike application versions, business service versions often track major business capability releases rather than technical versions. |
| owned_by | Owned by | reference | References sys_user for the CI owner. Often same as service_owner but can differ in matrix organizations with split technical/business ownership. |
| managed_by | Managed by | reference | References sys_user for day-to-day service management. Typically the technical lead while business_owner handles strategic decisions. |
| support_group | Support group | reference | References sys_user_group for incident escalation and service requests. Must be an active group or assignment routing will fail. |
| company | Company | reference | References core_company for multi-tenant environments. Essential for scoping business services to correct organizational units. |
| location | Location | reference | References cmn_location for primary service delivery location. More about business presence than technical hosting location. |
| cost_center | Cost center | reference | References cmn_cost_center for financial tracking. Critical for service costing and chargeback calculations in financial management processes. |
| life_cycle_stage | Life cycle stage | choice | Service lifecycle position like 'Requirements', 'Design', 'Build', 'Deploy', 'Operate', 'Retire'. Maps to ITIL service lifecycle stages. |
| life_cycle_stage_status | Life cycle stage status | choice | Status within current lifecycle stage like 'In Progress', 'Complete', 'On Hold'. Provides detailed view of service maturity progression. |

Page: https://thesnowball.co/table/cmdb_ci_service

## cmdb_rel_ci (CI Relationship)

The cmdb_rel_ci table stores relationships between Configuration Items in the CMDB module. Each record defines a directional relationship with parent and child CI references. Query performance degrades quickly without proper indexing on parent/child fields.

| Field | Label | Type | Notes |
|---|---|---|---|
| parent | Parent CI | reference | References the parent Configuration Item in this relationship. Always query with this field indexed—queries without parent filtering are extremely slow. |
| child | Child CI | reference | References the child Configuration Item in this relationship. Combined with parent, these two fields define the relationship direction and scope. |
| type | Relationship Type | reference | References cmdb_rel_type table defining the relationship semantics. Use getValue() not getDisplayValue() when filtering—displays as choice but stores as reference. |
| percent_outage | Percent Outage | integer | Percentage impact when parent CI fails. Defaults to 0 but should be 100 for most dependencies—discovery tools populate this incorrectly. |
| port | Port | string | Network port number for connection-based relationships. Empty for logical relationships like 'Contains' or 'Used by'. |
| connection_strength | Connection Strength | integer | Numeric strength of the relationship connection from 1-10. Used by impact analysis algorithms to weight dependency importance. |
| u_source | Source | string | Custom field tracking which discovery tool or process created this relationship. Useful for relationship cleanup and validation. |

Page: https://thesnowball.co/table/cmdb_rel_ci

## cmn_rota (On-call Rota)

The cmn_rota table defines on-call rotation schedules used by ITSM incident escalation rules. Part of the ITSM module, it links groups to time-based schedules for automatic assignment routing.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Display name for the rotation schedule. Must be unique and is commonly used in assignment rule conditions. |
| state | State | choice | Controls rotation availability ('active', 'inactive'). Inactive rotations remain in database but should be excluded from assignment logic. |
| group | Group | reference | References sys_user_group table. Links rotation to specific assignment groups for incident routing, but can be null. |
| start_date_time | Start Date/Time | glide_date_time | Rotation start timestamp in specified time zone. Critical for calculating current member assignments and must align with roster schedules. |
| end_date_time | End Date/Time | glide_date_time | Optional rotation end timestamp. If null, rotation continues indefinitely, which is common for ongoing operations. |
| rotation_interval_type | Rotation Interval Type | choice | Defines rotation frequency unit ('daily', 'weekly', 'monthly'). Works with rotation_interval_count to determine shift duration. |
| rotation_interval_count | Rotation Interval Count | integer | Number of time units per rotation cycle. Combined with rotation_interval_type, so '2' + 'weekly' = 2-week rotations. |
| time_zone | Time Zone | string | Time zone identifier for all rotation calculations. Affects date/time interpretation but doesn't auto-adjust for DST transitions. |
| description | Description | string | Free-text details about rotation purpose and coverage. Often contains escalation instructions and contact procedures. |
| use_business_calendar | Use Business Calendar | boolean | When true, rotation calculations respect holidays and non-business days defined in business calendar schedules. |
| business_calendar | Business Calendar | reference | References cmn_schedule table when use_business_calendar is true. Defines which days/hours count for rotation progression. |
| rotate_on | Rotate On | choice | Determines rotation trigger ('calendar', 'business_day'). Calendar rotations advance on schedule regardless of holidays. |
| member_count | Member Count | integer | Read-only count of rotation members. Auto-calculated from cmn_rota_member records but may lag behind actual count. |
| current_member | Current Member | reference | References sys_user table for currently assigned rotation member. Calculated field that updates based on rotation schedule. |
| next_member | Next Member | reference | References sys_user table for next scheduled rotation member. Useful for handoff notifications and planning. |
| rotation_start_date | Rotation Start Date | glide_date | Date-only version of start_date_time. Used in some rotation calculations but can cause time zone confusion. |

Page: https://thesnowball.co/table/cmn_rota

## cmn_schedule (Schedule)

The `cmn_schedule` table stores work schedules used for SLA calculations, business hours definitions, and on-call rotations across the Platform module. The critical thing to know: schedule spans are stored in separate tables, so you'll almost always need joins to get useful schedule data.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Schedule display name. Not enforced unique, which can break lookup scripts that assume unique names. |
| active | Active | boolean | Controls UI visibility but doesn't affect GlideSchedule API calculations — inactive schedules still work. |
| time_zone | Time zone | string | Time zone for schedule calculations. Uses ServiceNow-specific names, not standard JavaScript time zone identifiers. |
| type | Type | string | Schedule type like 'weekly' or 'monthly'. Appears as choice field but stores strings not documented in choice lists. |
| description | Description | string | Free text description. Often used to document business hours or coverage expectations. |
| parent | Parent | reference | References another cmn_schedule record for schedule inheritance. Rarely used in practice. |
| read_only | Read only | boolean | Prevents schedule modifications through the UI. System schedules are typically read-only. |
| document | Document | string | Stores schedule configuration as XML. Modified by schedule builder UI, not intended for direct script access. |

Page: https://thesnowball.co/table/cmn_schedule

## contract_sla (SLA Definition)

The contract_sla table stores SLA definitions with breach and warning thresholds, business calendars, and pause conditions for ITSM processes. This ITSM module table is the configuration backbone for all SLA calculations — records here define how task_sla records behave when attached to incidents, requests, and other tasks.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Display name for the SLA definition. Must be unique per table — you can't have duplicate SLA names for the same collection. |
| active | Active | boolean | Controls SLA visibility in selection lists, but doesn't prevent programmatic attachment. Inactive SLAs can still be manually applied through scripts or workflows. |
| collection | Table | string | Target table name where this SLA applies (incident, sc_req_item, etc.). No referential integrity checking — invalid table names are accepted. |
| condition | Condition | string | Encoded query string defining when this SLA applies to records. Complex conditions here can impact SLA attachment performance significantly. |
| duration | Duration | glide_duration | Default SLA duration in seconds, though breakdown records typically override this. Forms display in day/hour/minute format but store as total seconds. |
| schedule | Schedule | reference | References cmn_schedule table for business calendar. Changes to schedules don't recalculate existing task_sla due times, only affect new attachments. |
| pause_condition | Pause condition | string | Query condition that pauses SLA timers when true. Evaluates on every task state change, so expensive queries here impact overall task performance. |
| start_condition | Start condition | string | Condition that must be met before SLA timing begins. Empty means SLA starts immediately when attached to a task record. |
| stop_condition | Stop condition | string | Condition that stops SLA timing permanently when met. Different from pause_condition — stopped SLAs don't resume even if condition becomes false. |
| reset_condition | Reset condition | string | Condition that resets SLA timing back to start when met. Commonly used for SLAs that restart when tasks are reassigned or reopened. |
| workflow | Workflow | reference | References wf_workflow table for custom SLA processing logic. Most SLAs use the standard OOB workflow, custom workflows are for specialized timing rules. |
| enable_breakdown | Enable breakdown | boolean | Activates the breakdown rules system allowing different durations based on conditions. When true, contract_sla_breakdown records control actual timing. |
| retroactive | Retroactive | boolean | Whether this SLA applies to existing records when activated. False means only new records get this SLA, true includes pre-existing matching records. |
| relative_duration_works_on | Relative duration works on | choice | Defines the field used for relative duration calculations. Options include opened_at, sys_created_on, or other datetime fields on the target table. |
| timezone | Time zone | choice | Time zone for SLA calculations when different from system default. Affects due date calculations but not pause/resume logic timing. |
| sla_type | Type | choice | SLA category for reporting and organization. Values like Resolution, Response, etc. — purely descriptive, doesn't affect timing calculations. |

Page: https://thesnowball.co/table/contract_sla

## ecc_queue (ECC Queue)

The ecc_queue table manages message queues between the ServiceNow instance and MID Servers, supporting probes and sensors for ITOM/Discovery operations. Records are automatically created by the platform and have a rapid lifecycle—most queries should filter by timestamp or MID Server to avoid performance issues.

| Field | Label | Type | Notes |
|---|---|---|---|
| agent | MID Server | string | The MID Server name handling this queue record. Critical for filtering—queries without this can timeout due to cross-MID volume. |
| state | State | choice | Queue processing state (ready, sent, processed, error). Values mean different things for input vs. output queues—'ready' means waiting-to-send for output but received-ready-to-process for input. |
| queue | Queue | choice | Message direction: 'output' for instance-to-MID probes, 'input' for MID-to-instance sensor responses. Fundamental for understanding message flow. |
| topic | Topic | string | Probe or sensor name being executed. Key for filtering specific Discovery operations or debugging particular probe types. |
| name | Name | string | Human-readable description of the queue operation. Often contains target IP addresses or CI names for Discovery probes. |
| payload | Payload | xml | XML content of the probe or sensor data. Can be massive (>1MB) so avoid including in SELECT * queries or loops. |
| sequence | Sequence | integer | Message sequence number per MID Server, not global. Don't use for cross-MID ordering—increments independently per agent. |
| processed | Processed | glide_date_time | Timestamp when the message was processed. Null for records still in queue, useful for calculating processing latency. |
| error_string | Error String | string | Error details when state=error. Critical for probe failure troubleshooting but only populated on failed records. |
| source | Source | string | Context that created the queue record (Discovery, Service Mapping, etc.). Helps identify which ITOM process generated the message. |
| agent_correlator | Agent Correlator | string | MID Server correlation ID linking related probe/sensor pairs. Used internally for message matching and response correlation. |
| ecc_queue | Parent Queue | reference | Self-reference to parent queue record. Used for probe/sensor correlation where responses reference their originating probes. |
| sys_domain | Domain | domain_id | Domain separation field. MID Servers respect domain boundaries, so queue records inherit domain from the Discovery process. |
| response_to | Response To | string | Links input queue records to their originating output probe. Essential for tracking probe/sensor message pairs. |

Page: https://thesnowball.co/table/ecc_queue

## incident (Incident)

The incident table stores IT service interruptions and degradations managed through ITSM. It extends the task table and is the most commonly queried table in ServiceNow implementations. Before scripting against incidents, understand that state changes trigger SLA calculations and approval workflows inherited from task.

| Field | Label | Type | Notes |
|---|---|---|---|
| number | Number | string | Auto-generated unique identifier displayed to users. Format controlled by number maintenance and can include prefixes like INC0001234. |
| state | State | choice | Numeric workflow state (1=New, 2=In Progress, 6=Resolved, 7=Closed). Inherited from task but with incident-specific state values and transitions. |
| caller_id | Caller | reference | Reference to sys_user who reported the incident. Has reference qualifiers that may block inactive users in API integrations. |
| category | Category | choice | Primary categorization for routing and reporting. Often drives automatic assignment rules and SLA selection. |
| subcategory | Subcategory | choice | Secondary categorization dependent on category selection. Choice list filtered by category value through choice_list_dependent functionality. |
| impact | Impact | choice | Business impact level (1=High, 2=Medium, 3=Low). Combined with urgency to auto-calculate priority in most implementations. |
| urgency | Urgency | choice | Time sensitivity (1=High, 2=Medium, 3=Low). Works with impact in priority matrix calculations that may override manual priority settings. |
| priority | Priority | choice | Calculated from impact/urgency matrix but can be manually overridden. Business Rules may recalculate this automatically on updates. |
| assignment_group | Assignment group | reference | Reference to sys_user_group for work routing. Heavily indexed but requires additional filters for performance on large datasets. |
| assigned_to | Assigned to | reference | Individual assignee from sys_user table. Usually populated after assignment_group selection and may be restricted to group members. |
| short_description | Short description | string | Brief incident summary displayed in lists and notifications. Limited to 160 characters and heavily used in search indexing. |
| description | Description | string | Detailed incident information including symptoms and business impact. Can contain HTML formatting and grows large with copy/paste from monitoring tools. |
| work_notes | Work notes | journal_input | Internal notes visible to support staff only. Field value clears after insert as content moves to sys_journal_field table. |
| comments | Additional comments | journal_input | Customer-visible updates that appear in portal and email notifications. Value clears on insert like work_notes. |
| cmdb_ci | Configuration Item | reference | Reference to affected configuration item in cmdb_ci table. Drives automatic assignment and service impact calculations. |
| problem_id | Problem | reference | Links to related problem record for root cause tracking. Populated manually or through problem management workflows. |
| close_code | Close code | choice | Resolution categorization required for closure in most implementations. Choice list may be filtered by category or assignment group. |
| close_notes | Resolution notes | string | Detailed resolution information required when state changes to Resolved or Closed. Often feeds into knowledge base creation. |
| resolved_at | Resolved | glide_date_time | Timestamp when incident state changed to Resolved. Auto-populated by Business Rules and used for SLA calculations. |
| closed_at | Closed | glide_date_time | Timestamp when incident state changed to Closed. Final state for incident lifecycle and triggers archive processes. |
| reopen_count | Reopen count | integer | Number of times incident returned from Resolved/Closed to active states. Auto-incremented and used in quality metrics. |

Page: https://thesnowball.co/table/incident

## item_option_new (Catalog Variable)

The `item_option_new` table stores variable definitions for Service Catalog items — their types, labels, default values, and display rules. Part of the Service Catalog module, it defines the custom fields that appear on catalog item request forms. Each record represents one variable that can collect user input during the ordering process.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Internal variable name used in scripts and API calls. Must be unique within the catalog item or variable set scope. |
| question_text | Question | string | Display label shown to users on the catalog form. Supports HTML markup for formatting. |
| type | Type | choice | Variable type like 'string', 'boolean', 'reference', 'glide_list'. Controls the input widget and validation behavior. |
| cat_item | Item | reference | Reference to sc_cat_item table. Empty if variable belongs to a variable set instead of directly to a catalog item. |
| variable_set | Variable Set | reference | Reference to item_option_new_set table. Empty if variable belongs directly to a catalog item. |
| order | Order | integer | Display sequence on catalog forms. Accepts decimal values to enable insertion between existing variables. |
| active | Active | boolean | Controls if variable appears on catalog forms. Inactive variables remain in database but are hidden from users. |
| mandatory | Mandatory | boolean | Requires user input before form submission. Can be overridden by catalog UI policies. |
| read_only | Read only | boolean | Displays variable value but prevents user modification. Often used with calculated default values. |
| default_value | Default value | string | Initial field value on form load. Can contain JavaScript expressions for dynamic defaults. |
| reference | Reference | string | Target table name for reference-type variables. Works with reference_qual field for filtered lookups. |
| reference_qual | Reference qualifier | string | Filter expression for reference variables. Can reference other variable values using current.variables syntax. |
| tooltip | Help text | string | Explanatory text shown to users on hover or click. Supports basic HTML formatting. |
| attributes | Attributes | string | XML configuration for advanced variable behaviors like multi-row layouts or custom validation rules. |
| display_title | Display title | boolean | Shows variable as section header instead of input field. Used for form organization and grouping. |
| scale_min | Min | integer | Minimum value for numeric variables or minimum length for string variables. Used in client-side validation. |
| scale_max | Max | integer | Maximum value for numeric variables or maximum length for string variables. Enforced during form submission. |

Page: https://thesnowball.co/table/item_option_new

## item_option_new_set (Variable Set)

The item_option_new_set table stores variable sets — reusable groups of catalog variables owned by the Service Catalog module. Before scripting against this table, know that variable sets have their own activation model separate from catalog items.

| Field | Label | Type | Notes |
|---|---|---|---|
| title | Title | string | Display name of the variable set shown in catalog forms and admin interfaces. Not enforced as unique, so duplicates can exist causing admin confusion. |
| active | Active | boolean | Controls whether the variable set is available for use. Inactive sets still appear in catalog items that reference them but won't display variables to users. |
| internal_name | Internal name | string | Unique identifier used in scripting and API calls. Auto-generated from title on creation but can be manually changed, breaking existing script references. |
| description | Description | string | Detailed explanation of the variable set's purpose and usage. Supports HTML formatting but content is not automatically sanitized. |
| type | Type | choice | Distinguishes regular variable sets from container sets. Container sets group other variable sets, affecting form layout and client script execution order. |
| order | Order | integer | Display sequence within catalog forms when multiple variable sets are attached to the same item. Lower numbers appear first, but ordering is relative per item, not global. |
| layout | Layout | choice | Controls how variables within the set are arranged on catalog forms. Options include normal, two-column, and custom layouts that affect responsive rendering. |
| include_none | Include none | boolean | Adds a 'None' option to choice-type variables within the set. Commonly overlooked setting that affects variable validation behavior. |
| mandatory | Mandatory | boolean | Makes all variables in the set required for form submission. Individual variable mandatory settings can override this set-level default. |
| read_only | Read only | boolean | Prevents users from modifying any variables in the set after initial form load. Useful for pre-populated configuration data. |
| tooltip | Tooltip | string | Help text displayed when users hover over the variable set header. Supports basic HTML but complex formatting can break tooltip display. |
| applies_to | Applies to | string | Restricts which catalog item types can use this variable set. Common values include 'item', 'task', or specific table names for targeted usage. |
| availability | Availability | choice | Controls visibility scope across the platform. Options include global (all applications) or restricted to specific scopes, affecting cross-app reusability. |
| mobile_hide_unfulfilled | Mobile hide unfulfilled | boolean | Hides the variable set on mobile catalog interfaces when mandatory variables are not completed. Mobile-specific behavior that doesn't affect desktop forms. |
| container_tooltip | Container tooltip | string | Additional help text shown for container-type variable sets. Only applies when type field is set to container, otherwise ignored. |
| display_title | Display title | boolean | Controls whether the variable set title appears as a header section on catalog forms. When false, variables appear without grouping visual cues. |

Page: https://thesnowball.co/table/item_option_new_set

## kb_category (Knowledge Category)

The `kb_category` table stores categories within knowledge bases, forming a hierarchical tree structure used to organize knowledge articles. Owned by the Knowledge Management module, this table is critical for content taxonomy and navigation. The key thing developers must know is that categories are scoped to specific knowledge bases and form parent-child relationships through the `parent` field.

| Field | Label | Type | Notes |
|---|---|---|---|
| label | Label | string | The display name of the category shown to users. Not unique across knowledge bases, so multiple categories can share the same label. |
| kb_knowledge_base | Knowledge Base | reference | References the kb_knowledge_base table to scope this category to a specific knowledge base. Can be null for global categories accessible across all knowledge bases. |
| parent | Parent Category | reference | Self-referencing field to kb_category for hierarchical structure. Null indicates a root-level category. Requires circular reference validation to prevent infinite loops. |
| active | Active | boolean | Controls category visibility in user interfaces. Inactive categories remain in the database but are hidden from navigation and selection lists. |
| order | Order | integer | Controls display order among sibling categories at the same hierarchy level. Lower numbers appear first. Does not affect ordering across different parent levels. |
| description | Description | string | Longer text describing the category's purpose or scope. Often displayed as tooltips or help text in category selection interfaces. |
| image | Image | string | Stores the sys_id of an attachment record for category icons or images. Used in portal interfaces for visual category representation. |
| disable_commenting | Disable Commenting | boolean | When true, prevents user comments on knowledge articles within this category. Inherited by child categories unless explicitly overridden. |
| disable_rating | Disable Rating | boolean | When true, prevents user ratings on knowledge articles within this category. Affects article feedback mechanisms and analytics. |
| full_category | Full Category | string | Calculated field showing the complete category path from root to current category. Automatically maintained by the platform for display and search purposes. |
| topic | Topic | string | Optional topic classification for the category. Used for additional grouping and filtering beyond the hierarchical structure. |
| source | Source | choice | Indicates how the category was created (manual, imported, migrated). Important for data governance and migration tracking. |
| workflow_state | Workflow State | choice | Tracks category approval status in workflows. Categories may require approval before becoming available for article assignment. |
| manager | Manager | reference | References sys_user table for the user responsible for managing this category. Used for ownership tracking and approval routing. |
| url | URL | string | External URL associated with the category. May link to additional resources or redirect users to related content outside the knowledge base. |

Page: https://thesnowball.co/table/kb_category

## kb_knowledge (Knowledge Article)

The kb_knowledge table stores published knowledge articles in ServiceNow's Knowledge Management module. The critical gotcha: this table only contains published articles — drafts live elsewhere, and you'll need to understand the workflow_state field to query effectively.

| Field | Label | Type | Notes |
|---|---|---|---|
| number | Number | string | Auto-generated unique identifier for the article. Not the same as sys_id and can have multiple versions with the same number. |
| short_description | Title | string | The article title displayed in search results and lists. This is the primary field users see when browsing knowledge. |
| text | Text | html | The main article content as HTML. Can be very large and includes embedded images, formatting, and links. Avoid loading in list queries. |
| workflow_state | Workflow State | choice | Current state in the knowledge workflow (published, draft, review, retired, etc.). Critical for filtering - only 'published' articles are visible to end users. |
| kb_knowledge_base | Knowledge Base | reference | Reference to the knowledge base this article belongs to. Determines workflow rules, permissions, and organizational structure. |
| kb_category | Category | reference | Primary category reference to kb_category table. Articles can belong to multiple categories via m2m relationships. |
| author | Author | reference | Reference to sys_user who created the article. Different from sys_created_by as this can be updated through workflow processes. |
| valid_to | Valid To | glide_date_time | Expiration date for the article. Can be empty for articles without expiration. Check both this and workflow_state for active articles. |
| published | Published | glide_date_time | Date and time when the article was first published. Remains static even if article is republished after updates. |
| retired | Retired | glide_date_time | Date when article was retired. Only populated when workflow_state changes to 'retired'. |
| can_read_user_criteria | User Criteria | string | Advanced filter that restricts article visibility beyond role-based ACLs. Uses encoded query format to limit access by user attributes. |
| roles | Roles | string | Comma-separated list of roles required to view this article. Works in addition to standard knowledge ACLs. |
| version | Version | integer | Version number for this article iteration. Multiple versions can exist with the same article number but different content. |
| active | Active | boolean | Boolean flag but don't rely on this alone - check workflow_state instead. An article can be active=true but workflow_state='review'. |
| rating | Rating | decimal | Average user rating calculated from feedback. Automatically updated when users rate articles through the portal. |
| view_count | View Count | integer | Number of times the article has been viewed. Incremented automatically when users access the full article content. |
| useful_count | Useful Count | integer | Number of 'useful' votes from users. Part of the knowledge feedback system for measuring article effectiveness. |
| meta | Meta | string | Additional metadata in JSON format. Used by search engines and custom implementations for extended article attributes. |
| wiki | Wiki | html | Wiki-style content field that supports collaborative editing. Less commonly used than the main text field. |

Page: https://thesnowball.co/table/kb_knowledge

## kb_knowledge_base (Knowledge Base)

The kb_knowledge_base table defines top-level Knowledge Base containers that control language settings, ownership, and article workflow states. Part of the Knowledge module, each knowledge base acts as a container for kb_knowledge articles. Critical gotcha: querying knowledge articles requires joining through the knowledge base's workflow and language settings.

| Field | Label | Type | Notes |
|---|---|---|---|
| title | Title | string | The display name for this knowledge base. No uniqueness constraint means multiple KBs can have identical titles. |
| active | Active | boolean | Controls whether new articles can be created in this knowledge base. Existing articles remain searchable even when false. |
| owner | Owner | reference | References sys_user who owns this knowledge base. Can be empty, so always null-check before accessing owner properties. |
| language | Language | string | Language code like 'en' or 'es'. Not validated against sys_language table, so invalid codes break Portal searches silently. |
| description | Description | string | Long text description of the knowledge base purpose and scope. Often displayed in Portal knowledge base selection lists. |
| disable_commenting | Disable commenting | boolean | Controls whether users can comment on articles in this knowledge base. Defaults to false (commenting enabled). |
| disable_suggesting | Disable suggesting | boolean | When true, prevents users from suggesting improvements to articles. Important for controlled content workflows. |
| table_name | Table | string | Always 'kb_knowledge' for standard knowledge bases. Used internally for knowledge base type identification. |
| kb_managers | Knowledge managers | string | Comma-separated list of user sys_ids who can manage this knowledge base. Not a proper reference field. |
| kb_authors | Knowledge authors | string | Comma-separated list of user/group sys_ids who can author articles. Requires custom parsing to use effectively. |
| article_template | Article template | reference | References kb_template for default article structure. Controls field layout and required content sections. |
| workflow | Workflow | reference | References wf_workflow for article approval process. Determines who approves articles before publication. |
| enable_versioning | Enable versioning | boolean | Controls whether articles maintain version history. Performance impact when enabled for high-volume knowledge bases. |
| auto_retire_articles | Automatically retire articles | boolean | When enabled, articles automatically retire based on configured age thresholds. Requires retirement workflow setup. |
| retirement_cycle | Retirement cycle (days) | integer | Number of days before articles are flagged for retirement review. Only used when auto_retire_articles is true. |
| can_read_user_criteria | Who can read | string | Encoded user criteria defining read access. Complex format requiring sys_filter parsing to interpret programmatically. |
| can_contribute_user_criteria | Who can contribute | string | Encoded user criteria for contribution rights. Controls who can create, edit, and comment on articles. |
| use_approval | Use approval process | boolean | Determines if articles require approval before publication. Links to workflow field for approval configuration. |

Page: https://thesnowball.co/table/kb_knowledge_base

## live_group_profile (Collaboration Group)

The live_group_profile table stores real-time metadata for Connect collaboration groups in the Collaboration module. Before querying it, know that records are automatically managed by the Connect framework and direct manipulation can break real-time messaging functionality.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Group Name | string | Display name of the collaboration group. Not guaranteed unique across the system, and can be changed by group administrators. |
| description | Description | string | Optional description of the group's purpose. Often empty for system-generated groups but required for user-created groups. |
| state | State | choice | Group lifecycle state: 'active', 'inactive', 'archived'. Only active groups appear in Connect interfaces and receive new messages. |
| type | Group Type | choice | Group classification: 'public', 'private', 'system'. Determines visibility rules and who can join without invitation. |
| member_count | Member Count | integer | Cached count of active members. Updated by triggers but may be temporarily inconsistent during bulk operations. |
| created_by | Created By | reference | User who created the group, or 'system' for auto-generated groups. Group creator automatically becomes admin unless overridden. |
| last_activity | Last Activity | glide_date_time | Timestamp of most recent message or member activity. Updated asynchronously and may lag behind real activity by minutes. |
| context_table | Context Table | string | Table name when group is created for business context (e.g., 'incident', 'change_request'). Empty for standalone groups. |
| context_id | Context Record | string | Sys_id of the business record this group supports. Used with context_table to link groups to incidents, changes, etc. |
| topic | Topic | string | Optional topic or hashtag for group categorization. Used for group discovery and filtering in Connect interfaces. |
| avatar | Avatar | string | URL or identifier for group avatar image. Falls back to default system avatar if empty or invalid. |
| is_pinned | Pinned | boolean | Whether this group appears at the top of group lists. Typically set for high-priority or frequently-used groups. |
| auto_add_members | Auto Add Members | boolean | When true, automatically adds relevant users based on context (e.g., incident assignment group). Only applies to system groups. |
| notification_enabled | Notifications Enabled | boolean | Master switch for group notifications. When false, no member receives notifications regardless of individual preferences. |
| allow_external | Allow External Users | boolean | Whether users without Connect licenses can be added to this group. Requires special licensing and security approval. |
| retention_days | Message Retention Days | integer | Number of days to retain messages before archival. Zero means indefinite retention. Overrides system defaults. |
| max_members | Maximum Members | integer | Optional limit on group membership size. Zero or empty means no limit. Enforced when adding new members. |
| parent_group | Parent Group | reference | Reference to parent group for hierarchical group structures. Used in enterprise scenarios with nested team organization. |
| external_id | External ID | string | Identifier from external chat systems for integration scenarios. Must be unique within the external system context. |

Page: https://thesnowball.co/table/live_group_profile

## pa_indicators (Indicator)

The `pa_indicators` table stores Performance Analytics KPI definitions, including data collection queries, aggregation types, and collection schedules. Owned by the Performance Analytics module, it's the foundation for all PA dashboards and requires careful handling of the `aggregate_type` field when scripting collection logic.

| Field | Label | Type | Notes |
|---|---|---|---|
| active | Active | boolean | Controls whether the PA framework collects data for this indicator. Inactive indicators remain in cube configurations but don't execute collection queries. |
| aggregate_type | Aggregate type | choice | Defines how collected values are aggregated (SUM=1, COUNT=2, AVG=3, etc.). Database stores numeric codes, not display labels. |
| collection_query | Collection query | string | The GlideRecord query that extracts data from source tables. Supports complex conditions but syntax isn't validated until collection execution. |
| collection_schedule | Collection schedule | reference | References cmn_schedule table to determine when this indicator's data collection runs. Shared schedules affect multiple indicators simultaneously. |
| cube | Cube | reference | Primary cube assignment referencing pa_cubes. Indicators can belong to multiple cubes via pa_m2m_cube_indicator relationships. |
| description | Description | string | Business description of what this KPI measures. Displayed in dashboards and used for documentation generation scripts. |
| field | Field | string | The field name from the collection query's source table that provides the numeric value to aggregate. Must be a numeric field type. |
| name | Name | string | Unique identifier for the indicator within its cube context. Used in API calls and automation scripts to reference specific KPIs. |
| order | Order | integer | Display sequence in dashboards and reports. Doesn't affect collection execution order, which depends on collection_schedule timing. |
| table | Table | string | Source table name for the collection query. Must be a valid ServiceNow table that exists when the collection job executes. |
| target | Target | decimal | Optional target value for KPI goals. Used by dashboard widgets to show performance against targets but doesn't affect collection logic. |
| threshold_high | High threshold | decimal | Upper threshold for dashboard color coding and alerting. Purely visual—doesn't trigger automatic actions when exceeded. |
| threshold_low | Low threshold | decimal | Lower threshold for dashboard indicators. Combined with high threshold to create red/yellow/green status visualization. |
| type | Type | choice | Indicator category (Formula, Automated, Manual). Automated indicators use collection_query; Manual indicators accept external data input. |
| unit | Unit | string | Display unit for dashboard labels (e.g., 'minutes', 'count', '%'). Cosmetic only—changing doesn't convert existing snapshot values. |

Page: https://thesnowball.co/table/pa_indicators

## pa_scores (Score)

The pa_scores table stores historical KPI values captured by Performance Analytics jobs. Part of the Performance Analytics module, this table grows extremely large on mature instances — you must always filter by indicator and date range to avoid performance issues.

| Field | Label | Type | Notes |
|---|---|---|---|
| indicator | Indicator | reference | References pa_indicators table. Always filter by this field — it's the primary key for partitioning the massive dataset. |
| value | Value | string | The actual KPI value as a string. Use parseFloat() for numeric operations since it's not stored as a number type. |
| time_span_start | Time Span Start | glide_date_time | Start of the measurement period. Indexed field — use for date range queries instead of sys_created_on for better performance. |
| time_span_end | Time Span End | glide_date_time | End of the measurement period. Combine with time_span_start for precise date filtering in large datasets. |
| time_span | Time Span | choice | Aggregation period: daily, weekly, monthly, quarterly, yearly. Filter by this when you need specific granularity for trending. |
| cube_1 | Cube 1 | string | First dimensional breakdown (often assignment group sys_id). Contains sys_id values, not display names — join to reference table. |
| cube_2 | Cube 2 | string | Second dimensional breakdown (often category or priority). Like cube_1, stores sys_ids requiring lookup for readable values. |
| cube_3 | Cube 3 | string | Third dimensional breakdown. Additional breakdown dimension — check indicator configuration to understand what it represents. |
| cube_4 | Cube 4 | string | Fourth dimensional breakdown. Most indicators use 1-3 cubes, but complex breakdowns can go to cube_10. |
| score_state | Score State | choice | Values: collected, manual_override. Most scores are 'collected' — 'manual_override' indicates human adjustment of calculated value. |
| data_freshness | Data Freshness | choice | Indicates if this score represents the most current data or historical snapshot. Critical for real-time dashboard accuracy. |
| target | Target | string | Target value for this KPI measurement period. Like value field, stored as string despite being numeric data. |
| threshold_red | Red Threshold | string | Red threshold boundary for this score. Used by PA widgets to color-code performance against targets. |
| threshold_yellow | Yellow Threshold | string | Yellow threshold boundary. Widgets show yellow when value falls between yellow and red thresholds. |
| collection_time | Collection Time | glide_date_time | When PA job calculated this score. Different from time_span_start — this is the processing timestamp, not measurement period. |
| anomaly_score | Anomaly Score | decimal | Statistical deviation from expected value. PA uses this for anomaly detection and automated alerting on unusual patterns. |
| score_uuid | Score UUID | string | Unique identifier for this specific score calculation. PA uses this to prevent duplicate processing when jobs retry. |
| snapshot_id | Snapshot ID | reference | References pa_snapshots if this score is part of a snapshot collection. Null for regular time-series scoring. |

Page: https://thesnowball.co/table/pa_scores

## problem (Problem)

The problem table stores Problem Management records for root cause analysis of recurring incidents. Part of the ITSM module, it extends the task table with problem-specific states, categories, and relationships to incidents and known errors.

| Field | Label | Type | Notes |
|---|---|---|---|
| number | Number | string | Auto-generated problem identifier (PRB0001234). Uses the same numbering scheme as other task types but with PRB prefix. |
| problem_state | State | choice | Problem-specific workflow states: Draft, Assessment, Root Cause Analysis, Fix in Progress, Resolved, Closed. Different from incident states. |
| short_description | Short description | string | Brief problem summary, often derived from related incident patterns. Should describe the symptom, not the suspected cause. |
| description | Description | string | Detailed problem statement including symptom patterns, business impact, and investigation scope. Can be lengthy for complex problems. |
| category | Category | choice | Technical classification (Software, Hardware, Network, etc.). Often determines assignment routing and investigation approach. |
| subcategory | Subcategory | choice | More specific categorization dependent on category value. Uses reference qualifiers to show relevant options only. |
| priority | Priority | choice | Business priority (1-Critical to 5-Planning). Usually derived from highest priority of related incidents, not calculated automatically. |
| impact | Impact | choice | Business impact level (1-High to 3-Low). Represents cumulative impact across all related incidents and affected services. |
| urgency | Urgency | choice | Time sensitivity (1-High to 3-Low). Often stays constant throughout problem lifecycle, unlike incidents which may lose urgency. |
| assignment_group | Assignment group | reference | Current owning group for investigation. May change as root cause analysis progresses through technical domains. |
| assigned_to | Assigned to | reference | Individual investigator. Problems often require senior technical staff rather than standard assignment pool rotation. |
| cmdb_ci | Configuration Item | reference | Primary affected CI. Critical for impact analysis and change coordination. Often the common element across related incidents. |
| business_service | Business Service | reference | Affected business service for impact assessment. Used to identify stakeholders and calculate business cost of the problem. |
| cause_notes | Root cause notes | string | Detailed root cause analysis findings. Key field for Knowledge Management and preventing future occurrences. |
| workaround | Workaround | string | Temporary mitigation steps. Often copied to related incidents and Known Error records for consistent application. |
| fix_notes | Fix notes | string | Permanent solution details including implementation steps and verification procedures. Links to change requests for fixes. |
| known_error | Known error | boolean | Flag indicating root cause is understood. Doesn't automatically create Knowledge articles — requires workflow trigger. |
| problem_type | Type | choice | Investigation type: Reactive (incident-driven), Proactive (trend analysis), or Post Implementation Review. Affects SLAs and workflows. |
| related_incidents | Related Incidents | string | Display-only field showing linked incident count. Actual relationships stored in problem_task table, not queryable directly. |
| major_problem | Major problem | boolean | High-visibility flag for problems affecting critical services or multiple business units. Triggers additional approval and communication. |

Page: https://thesnowball.co/table/problem

## sc_cat_item (Catalog Item)

The sc_cat_item table stores Service Catalog items that users can order. Owned by the Service Catalog module, this table extends sc_cat_item_producer and drives the entire catalog ordering process. The critical thing to know: catalog items are tightly coupled to variables and workflows, making joins to io_set_item and wf_workflow essential for most real-world scenarios.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Display name shown to users in the catalog. This is what appears in search results and catalog views, not the sys_name field. |
| active | Active | boolean | Controls catalog visibility but doesn't stop processing existing requests. Inactive items remain in dropdowns for historical request editing. |
| category | Category | reference | Reference to sc_category. Determines catalog navigation structure and inheritance of category-level properties like approvals and fulfillment groups. |
| workflow | Workflow | reference | Reference to wf_workflow for request fulfillment. Can be null if using Flow Designer (check flow_designer_flow field) or simple approval workflows. |
| flow_designer_flow | Flow | reference | Reference to sys_hub_flow for Flow Designer-based fulfillment. Takes precedence over the workflow field when both are populated. |
| price | Price | decimal | Base price in default currency. Final pricing may include variable-based additions and dynamic pricing scripts that execute at request time. |
| recurring_price | Recurring Price | decimal | Ongoing subscription cost for recurring services. Used with recurring_frequency to calculate total cost of ownership for financial reporting. |
| short_description | Short Description | string | Brief summary shown in catalog tiles and search results. Limited display space means this should be concise and descriptive. |
| description | Description | html | Full HTML description with formatting and images. Rendered in the catalog item detail view and can include dynamic content via catalog macros. |
| state | State | choice | Workflow state for catalog items that go through approval processes. Common values: 1=New, 3=Published, 7=Retired. Not the same as active status. |
| delivery_time | Delivery Time | glide_duration | Expected fulfillment duration respecting business schedules. Stored as duration value, not computed delivery date - calculations happen at request time. |
| availability | Availability | choice | Controls when item appears in catalog: on_desktop, on_mobile, both, or specific conditions. Affects Service Portal and platform UI display logic. |
| visible_bundle | Visible Bundle | boolean | Shows bundled items as expandable groups in the catalog. When false, only the parent bundle appears - child items are hidden from direct selection. |
| template | Template | reference | Reference to another sc_cat_item used as template for variable inheritance. Changes to template variables don't automatically update derived items. |
| vendor | Vendor | reference | Reference to core_company for the item supplier. Used in procurement workflows and vendor performance reporting, not just informational. |
| cost | Cost | decimal | Internal cost to organization, separate from user-facing price. Used for financial reporting and cost center allocations in request fulfillment. |
| picture | Picture | user_image | Display image for catalog tiles and item details. Platform automatically generates thumbnails but large images impact Service Portal performance. |
| preview | Preview | string | Link to external preview or demo URL. Opens in new window/tab when users click preview button in catalog interface. |
| model | Model | reference | Reference to cmdb_model for hardware items. Links catalog requests to CMDB for asset lifecycle management and configuration item creation. |
| group | Fulfillment Group | reference | Reference to sys_user_group for default assignment. Can be overridden by workflow logic but provides fallback routing for request fulfillment. |

Page: https://thesnowball.co/table/sc_cat_item

## sc_category (Catalog Category)

The sc_category table stores Service Catalog categories that organize catalog items into hierarchical structures. Part of the Service Catalog module, it supports parent/child relationships where categories can contain subcategories. The key gotcha: always filter by active=true since inactive parent categories hide their entire subtrees from end users.

| Field | Label | Type | Notes |
|---|---|---|---|
| title | Title | string | Display name for the category shown in catalog navigation. Gets HTML-encoded in some portal contexts but not others. |
| description | Description | string | Rich text description supporting HTML markup. Displayed in category detail views and used for search indexing. |
| parent | Parent Category | reference | Self-reference to another sc_category record. Null for root-level categories. No built-in circular reference prevention. |
| active | Active | boolean | Controls category visibility. Inactive parent categories hide entire subtrees regardless of child active status. |
| order | Order | integer | Sort order for sibling categories within the same parent level. Lower numbers appear first. Doesn't affect cross-hierarchy ordering. |
| image | Image | string | Stores sys_attachment.sys_id for category icons. References can break if attachments are deleted without cascade cleanup. |
| homepage_image | Homepage image | string | Larger image displayed in catalog homepage views. Also stores attachment sys_id like the image field. |
| icon | Icon | string | CSS class name for FontAwesome or custom icon fonts. Used in tree navigation and mobile catalog views. |
| catalog | Catalog | reference | References sc_catalog table. Categories belong to specific catalogs and inherit catalog-level visibility rules. |
| available_for | Available for | string | Comma-separated list of sys_user_group.sys_id values. Controls which groups can see this category. Empty means available to all. |
| sc_catalogs | Catalogs | glide_list | Many-to-many relationship allowing categories to appear in multiple catalogs. Used when category structure spans catalogs. |
| show_in_cms | Show in CMS | boolean | Controls visibility in Content Management System views. Separate from catalog visibility and often confuses developers. |
| entitlement_script | Entitlement script | script_plain | Server-side JavaScript for custom visibility logic. Must return true/false. Executes on every category access check. |
| roles | Roles | string | Comma-separated role names required to see this category. More restrictive than available_for groups. |
| header_icon | Header Icon | string | Alternative icon field used in specific portal themes. Behavior varies by Service Portal template implementation. |
| full_description | Full description | html | Extended HTML content for category landing pages. Supports embedded images and complex markup unlike the basic description field. |
| keywords | Keywords | string | Space or comma-separated search terms. Indexed for catalog search but doesn't support stemming or fuzzy matching. |
| location | Location | reference | References cmn_location table. Restricts category visibility to users in specific locations when location-based entitlements are enabled. |
| mobile_hide_description | Mobile hide description | boolean | Hides description text in mobile Service Portal views. Desktop visibility unaffected. |

Page: https://thesnowball.co/table/sc_category

## sc_item_option (Catalog Item Option)

The sc_item_option table stores variable values submitted with catalog item orders in the Service Catalog module. Each record represents a single question response linked to an sc_req_item record. Developers must join through request_item to access the parent RITM data.

| Field | Label | Type | Notes |
|---|---|---|---|
| request_item | Request Item | reference | Links to sc_req_item parent record. This field is indexed and should be included in every query for performance. |
| item_option_new | Item Option | reference | References the variable definition in item_option_new table. Use this to get variable names, types, and configuration details. |
| value | Value | string | The actual submitted value. For reference variables, contains sys_id. For choice lists, contains the choice value, not the label. |
| display_value | Display Value | string | User-friendly display of the value. Shows display names for references and choice labels. Never use for queries or comparisons. |
| order | Order | integer | Display sequence from the catalog form. Not reliable for sorting—gaps and duplicates exist when variables are reordered. |
| mandatory | Mandatory | boolean | Indicates if the variable was required when submitted. Useful for validation logic but doesn't guarantee value exists. |
| visible | Visible | boolean | Whether the variable was visible to the user during submission. Hidden variables still create records with default values. |
| sc_item_option | Catalog Item Option | reference | Self-referencing field used for variable dependencies and conditional logic. Links child variables to their parent conditions. |
| no_export | No Export | boolean | Excludes sensitive variables from exports and integrations. Check this before sending data to external systems. |

Page: https://thesnowball.co/table/sc_item_option

## sc_req_item (Requested Item (RITM))

The sc_req_item table stores individual catalog items (RITMs) ordered within Service Catalog requests. Owned by the Service Catalog module and extends the task table. Most fulfillment workflows, catalog Business Rules, and approval processes script against this table rather than the parent sc_request.

| Field | Label | Type | Notes |
|---|---|---|---|
| state | State | choice | Current workflow state using integer values: -5 (Pending Approval), 1 (Work in Progress), 3 (Closed Complete). Query by number, never by display value. |
| stage | Stage | choice | High-level fulfillment phase like 'Request Approved' or 'Fulfillment'. Auto-updated by Business Rules when state changes - don't set manually. |
| request | Request | reference | References the parent sc_request record. Use request.requested_for to get the actual recipient, not opened_by who might be an admin or delegate. |
| cat_item | Catalog Item | reference | References sc_cat_item defining what was ordered. Contains fulfillment rules, approval mappings, and delivery SLAs used by automation. |
| quantity | Quantity | integer | Number of items requested. Used for cost calculations and inventory management. Defaults to 1 but can be set by catalog item configuration. |
| price | Price | decimal | Total cost for this RITM (quantity × unit price). Calculated from cat_item.cost unless overridden by variable-driven pricing rules. |
| recurring_price | Recurring Price | decimal | Monthly or periodic cost for subscription items. Used by financial management for ongoing cost allocation and budgeting. |
| approval | Approval | choice | Overall approval status: not requested, pending, approved, rejected. Check sysapproval_approver for individual approver details and logic. |
| delivery_address | Delivery Address | string | Physical delivery location for hardware items. Often populated from user's location record but can be overridden by delivery variables. |
| estimated_delivery | Estimated Delivery | glide_date_time | Expected completion date calculated from cat_item.delivery_time and business calendar. Updated by fulfillment workflows as work progresses. |
| received | Received | glide_date_time | When the requester confirmed receipt of the item or service. Populated by notifications or self-service portals, triggers final closure. |
| backordered | Backordered | glide_date_time | Set when item is out of stock or delayed. Triggers notifications to requesters and updates delivery estimates in fulfillment dashboards. |
| context | Context | reference | Links to the sc_request parent. Redundant with request field but used by some OOB workflows - maintain consistency between both fields. |
| configuration_item | Configuration Item | reference | References cmdb_ci when fulfillment creates or modifies a configuration item. Used for asset tracking and service mapping integration. |
| opened_by | Opened By | reference | Who submitted the request - may be admin or delegate. For actual recipient, use request.requested_for. Critical distinction for approval and notification logic. |
| variables | Variables | variables | Virtual field for accessing catalog variables. Don't query this directly - use sc_item_option_mtom table or getRITMVariableValue() API instead. |

Page: https://thesnowball.co/table/sc_req_item

## sc_request (Service Catalog Request)

The sc_request table stores Service Catalog orders and acts as the parent record that groups related catalog items (RITMs). Owned by the Service Catalog module, it extends the task table and drives the entire catalog fulfillment workflow from order placement through approval and delivery.

| Field | Label | Type | Notes |
|---|---|---|---|
| state | State | integer | Catalog request state (1=Draft, 2=Waiting for Approval, 3=Approved, etc.). Different values than standard task states. |
| request_state | Request State | choice | String version of state field ('submitted', 'approved', 'closed_complete'). Often confused with the integer state field. |
| stage | Stage | choice | High-level workflow stage ('Request Submitted', 'Waiting for Approval', 'Fulfillment'). Aggregated from child RITM stages. |
| requested_for | Requested for | reference | User receiving the catalog items. Can differ from opened_by when someone orders on behalf of another user. |
| opened_by | Opened by | reference | User who submitted the catalog order. Inherited from task table but critical for catalog security and approvals. |
| price | Price | currency | Total cost of all RITMs in this request. Calculated field—updates automatically when child RITM prices change. |
| delivery_address | Delivery address | string | Where physical items should be delivered. Inherited by child RITMs but can be overridden at item level. |
| special_instructions | Special instructions | string | User-provided delivery or setup instructions. Appears on RITM fulfillment tasks and approval forms. |
| approval | Approval | reference | Points to the most recent approval record only. Use approval_history or sysapproval_approver for complete approval chains. |
| approval_history | Approval history | glide_list | Comma-separated list of approval record sys_ids. Better than approval field for tracking multi-step approval workflows. |
| approval_set | Approval set | reference | Groups related approvals together. Useful when multiple approvers must approve the same request simultaneously. |
| request_id | Request ID | string | User-friendly request number (REQ0001234). Auto-generated and displayed to users instead of sys_id. |
| parent | Parent | reference | Rarely used in catalog context but inherited from task. Usually null for top-level catalog requests. |
| due_date | Due date | glide_date_time | When the entire request should be fulfilled. Calculated from SLA or manually set. Child RITMs may have different due dates. |
| correlation_display | Correlation display | string | Groups related requests for reporting. Often populated by integrations or bulk ordering processes. |
| catalog | Catalog | reference | Which service catalog this request came from. Important for multi-catalog implementations with different approval workflows. |
| business_service | Business Service | reference | Links request to CMDB business service for impact analysis. Usually inherited from the catalog item configuration. |
| reassignment_count | Reassignment count | integer | Tracks how many times the request was reassigned. Useful for identifying problematic approval chains or fulfillment bottlenecks. |

Page: https://thesnowball.co/table/sc_request

## sc_task (Catalog Task)

The sc_task table stores catalog fulfillment tasks created from Requested Items (RITMs) in the Service Catalog module. It extends the task table and represents the actual work items that fulfill catalog requests. Before querying, understand that these records have complex state flows and automatic assignment rules that differ from standard tasks.

| Field | Label | Type | Notes |
|---|---|---|---|
| request_item | Request Item | reference | References the parent sc_req_item record. This relationship cannot be changed after task creation and determines variable access and context. |
| state | State | choice | Task state using catalog-specific values: 1=Open, 2=Work in Progress, 3=Closed Complete, 4=Closed Incomplete. Different from standard task states. |
| cat_item | Catalog Item | reference | References the sc_cat_item that generated this task. Inherited from parent RITM but useful for direct catalog item queries and fulfillment group lookups. |
| assignment_group | Assignment Group | reference | Fulfillment team responsible for this task. Often populated automatically based on catalog item configuration or assignment rules. |
| assigned_to | Assigned To | reference | Individual fulfiller assigned to complete this task. Can be set manually or through auto-assignment Business Rules. |
| requested_for | Requested For | reference | End user who will receive the catalog item. Inherited from parent RITM and cannot be changed on the task level. |
| opened_by | Opened By | reference | User who originally submitted the catalog request. Often different from requested_for in scenarios where someone requests items for others. |
| cmdb_ci | Configuration Item | reference | Links to the configuration item being provisioned or modified. Crucial for asset lifecycle management and automated provisioning workflows. |
| location | Location | reference | Delivery or installation location for the request. Inherited from requested_for user but can be overridden for shipping and fulfillment routing. |
| business_service | Business Service | reference | Business service impacted by this fulfillment task. Used for service mapping and business impact analysis during fulfillment activities. |
| priority | Priority | choice | Task priority typically inherited from catalog item or calculated based on requester VIP status. Values: 1=Critical, 2=High, 3=Moderate, 4=Low, 5=Planning. |
| due_date | Due Date | glide_date_time | Expected completion date for fulfillment. Often calculated automatically based on catalog item SLA definitions and request submission time. |
| work_notes | Work Notes | journal_input | Internal fulfillment notes visible to fulfillment team only. Used to track progress, issues, and coordination between fulfillment groups. |
| short_description | Short Description | string | Brief task description often auto-populated from catalog item name and requested_for user. Format typically: '[Catalog Item] for [User]'. |
| description | Description | string | Detailed task description including fulfillment instructions. May contain variable values or custom instructions from the catalog item definition. |
| approval | Approval | choice | Approval status if this task requires approval workflow: not requested, requested, approved, rejected. Links to sysapproval_approver records. |
| made_sla | Made SLA | boolean | Indicates whether task was completed within SLA timeframe. Calculated field that updates when task closes based on due_date comparison. |
| calendar_integration | Calendar Integration | choice | Enables Outlook calendar integration for scheduling fulfillment activities. Values control calendar event creation and synchronization behavior. |
| correlation_id | Correlation ID | string | External system correlation identifier for integration scenarios. Used to track fulfillment status across multiple systems and orchestration tools. |
| user_input | User Input | journal_input | Input from the requester visible to both fulfillment team and requester. Used for additional requirements or clarification during fulfillment. |

Page: https://thesnowball.co/table/sc_task

## sn_customerservice_case (Customer Case)

The sn_customerservice_case table stores customer service case records in the Customer Service Management (CSM) application. It extends the task table and represents customer-reported issues, requests, and complaints managed by service agents.

| Field | Label | Type | Notes |
|---|---|---|---|
| state | State | choice | Case workflow state using values 1,2,3,6,7 (skips 4,5). Unlike incidents, 'Resolved' vs 'Closed' distinction affects customer portal visibility. |
| account | Account | reference | References customer_account table. Critical for ACL security and agent workspace filtering. Never null for valid cases. |
| contact | Contact | reference | References customer_contact table. Can be null even when caller_id populated — contact represents the customer hierarchy relationship. |
| escalation | Escalation | integer | Auto-increments on SLA breaches. Drives escalation workflows but manual changes don't trigger automation. |
| category | Category | choice | Drives assignment rules and SLA selection. Values controlled by sys_choice table, often customized per customer implementation. |
| subcategory | Subcategory | choice | Dependent choice based on category selection. Used for detailed case classification and reporting. |
| priority | Priority | choice | Inherited from task table. Often auto-calculated based on customer tier and category combination. |
| origin_id | Origin | reference | References sys_cs_origin table. Tracks whether case came from email, phone, chat, portal, etc. |
| product | Product | choice | Links to product catalog for entitlement validation. Critical for routing to product-specific support teams. |
| correlation_id | Correlation ID | string | External system identifier for integration scenarios. Must be unique when populated to prevent duplicate case creation. |
| customer_satisfaction | Customer Satisfaction | choice | CSAT score typically populated via survey workflows. Null until customer provides feedback after case resolution. |
| resolved_at | Resolved | glide_date_time | Auto-populated when state changes to Resolved. Different from closed_at — affects customer portal case visibility. |
| follow_up | Follow up | glide_date_time | Used for proactive customer outreach scheduling. Drives follow-up task creation via scheduled jobs. |
| reassignment_count | Reassignment count | integer | Auto-increments on assignment changes. High values trigger escalation workflows and management alerts. |
| business_impact | Business Impact | choice | Customer-reported impact level. Often different from system-calculated priority — used for escalation decisions. |
| watch_list | Watch list | glide_list | List of sys_user records to notify on case updates. Comma-separated user sys_ids stored as string. |
| case_data | Case Data | json | JSON field for storing structured case-specific information. Often used for integration payload storage and custom field extensions. |

Page: https://thesnowball.co/table/sn_customerservice_case

## sn_si_incident (Security Incident)

The sn_si_incident table stores security incident records in the SecOps module, extending the task table with threat intelligence and security-specific fields. Before querying, know that it inherits task's complex state management while adding security-specific workflow states.

| Field | Label | Type | Notes |
|---|---|---|---|
| state | State | choice | Security incident workflow state using SecOps-specific values (0=Draft, 1=Analysis, 2=Containment, 3=Eradication, 4=Recovery, 6=Resolved, 7=Closed). Different from standard incident states. |
| classification | Classification | choice | Security incident type classification (Malware, Phishing, Data Breach, etc.). Drives automated workflow routing and analyst assignment rules. |
| attack_vector | Attack Vector | choice | Primary attack method used (Email, Web Application, Network, etc.). Populates asynchronously after creation via threat intelligence integration. |
| mitre_technique | MITRE ATT&CK Technique | reference | References sn_ti_mitre_technique table for ATT&CK framework mapping. May be empty initially and populated during analysis phase. |
| threat_intel_observables | Threat Intelligence Observables | glide_list | Comma-separated sys_ids referencing sn_ti_observable records. Cross-scope references can cause access issues in custom scripts. |
| security_domain | Security Domain | reference | References security domain for record-level access control. Analysts only see incidents within their assigned domains. |
| risk_score | Risk Score | integer | Calculated risk score (0-100) based on threat intelligence and asset criticality. Updated automatically by threat scoring Business Rules. |
| source_id | Source ID | string | External system identifier (SIEM alert ID, endpoint tool case number). Used for correlation and duplicate prevention in automated creation. |
| source_system | Source System | string | Originating security tool or system name. Critical for integration mapping and automated enrichment workflows. |
| containment_status | Containment Status | choice | Threat containment progress (Not Started, In Progress, Complete). Independent of main state field for detailed tracking. |
| artifacts_collected | Artifacts Collected | boolean | Flag indicating forensic evidence collection status. Triggers retention policy and legal hold workflows when true. |
| affected_users | Affected Users | integer | Count of impacted user accounts. Automatically calculated from related user security events and CI relationships. |
| business_impact | Business Impact | choice | Business impact level (None, Low, Medium, High, Critical). Drives SLA timers and executive notification workflows. |
| sla_due | SLA Due | glide_date_time | Security SLA deadline calculated from classification and business impact. Timezone handling matches assigned_to user preferences. |
| false_positive | False Positive | boolean | Marks incident as false positive for metrics exclusion. Changing this triggers tuning workflows for source detection systems. |
| parent_incident | Parent Security Incident | reference | Self-referencing field for incident hierarchy. Uses same table reference with qualified domain restrictions. |
| investigation_notes | Investigation Notes | journal_input | Analyst investigation journal with automatic timestamping. Searchable across incidents for pattern analysis and threat hunting. |
| detection_method | Detection Method | choice | How the incident was initially detected (Automated Tool, User Report, Hunting, etc.). Used for detection capability metrics. |

Page: https://thesnowball.co/table/sn_si_incident

## sn_vul_vulnerable_item (Vulnerable Item)

The sn_vul_vulnerable_item table stores vulnerability response tracking records that link CVEs to Configuration Items in the SecOps module. The critical thing to know: this table creates the many-to-many relationship between vulnerabilities and affected CIs, so one CVE can have multiple vulnerable item records.

| Field | Label | Type | Notes |
|---|---|---|---|
| vulnerability | Vulnerability | reference | References sn_vul_vulnerability table (not direct CVE records). This is the many-to-many link allowing one CVE to affect multiple CIs. |
| configuration_item | Configuration Item | reference | References any cmdb_ci record. Can point to servers, applications, network devices - performance degrades with mixed CI type queries. |
| state | State | choice | Vulnerability-specific states like 'Investigate', 'Remediate', 'Verify' - not standard task states. Don't assume normal task workflow applies. |
| priority | Priority | choice | Inherited from task table but often auto-populated based on vulnerability severity and CI criticality scoring algorithms. |
| first_found | First Found | glide_date_time | When this vulnerability was first discovered on this CI. Key field for aging reports and SLA calculations. |
| last_found | Last Found | glide_date_time | Most recent scan confirming this vulnerability still exists. Used to determine if vulnerabilities have been resolved. |
| source | Source | string | Identifies which vulnerability scanner or source created this record. Critical for deduplication logic across multiple scanners. |
| external_reference | External Reference | string | Scanner-specific identifier for this vulnerability instance. Used to sync status updates back to scanning tools. |
| risk_score | Risk Score | integer | Calculated risk value combining CVE severity with CI business impact. Often auto-updated by Business Rules. |
| remediation_details | Remediation Details | string | Text field containing fix instructions or patch information. Can be auto-populated from vulnerability feeds or manually updated. |
| closed_code | Resolution Code | choice | Reason for closure: Fixed, Risk Accepted, False Positive, etc. Required for proper vulnerability lifecycle tracking and reporting. |
| business_criticality | Business Criticality | choice | Business impact rating often inherited from the CI record. Drives priority calculations and assignment routing. |
| patch_available | Patch Available | boolean | Indicates if vendor has released a fix. May be auto-updated from vulnerability feeds or manually set by security teams. |
| exploit_available | Exploit Available | boolean | Whether known exploits exist in the wild. Significantly impacts priority calculations and remediation urgency. |
| assignment_group | Assignment Group | reference | Inherited from task table. Can be null if auto-assignment fails - always null-check before assuming assignments exist. |

Page: https://thesnowball.co/table/sn_vul_vulnerable_item

## sp_page (Portal Page)

The sp_page table defines Service Portal page layouts, URL routing, and widget container structures. Owned by Service Portal module. Key gotcha: the layout field stores JSON that defines the entire page structure — modify it wrong and you'll break the page rendering.

| Field | Label | Type | Notes |
|---|---|---|---|
| id | Page ID | string | Unique URL route identifier for this page. Used in portal URLs after the portal path — must be unique within a portal instance but can be duplicated across different portals. |
| title | Title | string | Display name for the page shown in browser tabs and navigation menus. Not indexed, so avoid querying on this field for performance reasons. |
| short_description | Short description | string | Brief description of page purpose, often used in tooltips or admin interfaces. Limited to 255 characters unlike the longer description field. |
| layout | Page layout | json | JSON structure defining the complete page layout including rows, columns, and widget placements. Modifying this directly can break page rendering — use Portal Designer instead. |
| css | CSS - dependencies | string | CSS includes and dependencies for this page. Can reference Bootstrap classes, custom CSS files, or inline styles that apply specifically to this page layout. |
| bootstrap_alt | Alternative CSS framework | string | Alternative CSS framework reference when not using standard Bootstrap. Rarely used but allows pages to opt into different responsive frameworks. |
| public | Public | boolean | Allows anonymous access to this page when true. However, portal-level authentication settings still apply — a public page in a private portal still requires login. |
| roles | Roles | string | Comma-separated list of roles required to access this page. These are additive with portal-level role requirements — users need both portal AND page access. |
| active | Active | boolean | Controls whether the page is available for rendering. Inactive pages return 404 errors, but may still appear in cached navigation menus for up to 30 minutes. |
| internal | Internal | boolean | Marks system-generated pages that shouldn't appear in user navigation menus. These pages are accessible via direct URL but hidden from automated menu generation. |
| category | Category | reference | References sys_db_object for categorizing pages functionally. Used primarily for organization in Portal Designer and has no impact on page behavior or access control. |
| order | Order | integer | Numeric sort order for this page within navigation contexts. Lower numbers appear first in menus, but actual menu ordering also depends on sp_menu configuration. |
| draft | Draft | boolean | Indicates a page under development that shouldn't be visible to end users. Draft pages are accessible to sp_admin role users but hidden from standard portal navigation. |
| home_page | Home page | boolean | Designates this as the default landing page for its assigned portals. Each portal should have exactly one home page — multiple home pages create unpredictable routing behavior. |
| theme | Theme | reference | References sp_theme record for custom styling. Overrides portal-level theme settings for this specific page, allowing mixed themes within a single portal instance. |

Page: https://thesnowball.co/table/sp_page

## sp_widget (Widget)

The sp_widget table stores Service Portal widget definitions, containing the HTML template, CSS, client/server scripts, and Angular controller for each widget. Part of the Service Portal module. Query with caution in server scripts — widget records contain large text fields that can impact performance.

| Field | Label | Type | Notes |
|---|---|---|---|
| id | Widget ID | string | Unique technical identifier used in code and URLs. Must follow JavaScript variable naming rules since it becomes an Angular module name. |
| name | Name | string | Display name shown in the Service Portal designer. Can contain spaces and special characters unlike the ID field. |
| template | Body HTML template | html | Angular HTML template with ServiceNow-specific directives. Supports two-way data binding to the widget's server data object. |
| css | CSS | css | Scoped CSS that applies only to this widget instance. Automatically prefixed with widget-specific selectors to prevent style bleeding. |
| script | Server script | script | Server-side JavaScript that executes before template rendering. Has access to the special 'data' object and '$sp' API but not standard glide APIs. |
| client_script | Client script | script | Angular controller JavaScript that runs in the browser. Receives the server data object and can make $http calls back to the server. |
| option_schema | Option schema | json | JSON schema defining configurable options for widget instances. Validates option values and generates the instance configuration UI. |
| public | Public | boolean | Controls visibility in the Service Portal designer widget picker. Private widgets can only be added programmatically. |
| roles | Roles | string | Comma-separated list of roles required to view this widget. Empty means no role restriction, but portal page ACLs still apply. |
| servicenow | ServiceNow | boolean | Identifies out-of-box widgets. Never set to true on custom widgets as it affects upgrade behavior and support. |
| category | Category | string | Organizes widgets in the designer palette. Custom categories appear alongside out-of-box ones like 'form' and 'data'. |
| description | Description | string | Tooltip text shown in the designer widget picker. Should explain the widget's purpose and any configuration requirements. |
| docs | Documentation | html | Rich text documentation for developers. Appears in the widget editor's documentation tab but nowhere in the runtime portal. |
| field_list | Field list | string | Comma-separated list of table fields this widget commonly displays. Used for form widgets to auto-populate field options. |
| has_preview | Has preview | boolean | Indicates if this widget supports preview mode in the designer. Complex widgets often disable preview for performance. |
| internal | Internal | boolean | Marks widgets for internal ServiceNow use only. Internal widgets may change behavior in upgrades without notice. |
| link | Link | script | Server-side script that executes when the widget receives AJAX calls from its client controller. Returns data to the client. |
| data_table | Data table | string | Table name this widget primarily displays data from. Used by the platform to suggest relevant widgets when building forms. |

Page: https://thesnowball.co/table/sp_widget

## sys_atf_test (ATF Test)

The `sys_atf_test` table stores Automated Test Framework (ATF) test definitions in the Development module. Records contain test steps as JSON, execution state, and pass/fail results—but test steps are stored as serialized objects that require careful parsing.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Test name displayed in ATF interface and reports. Must be unique within the application scope—duplicates cause execution conflicts. |
| state | State | choice | Test lifecycle state: draft, active, or retired. Draft tests can still execute manually, so don't rely on this for execution control. |
| test_definition | Test Definition | json | Serialized JSON containing all test steps and configuration. Not queryable with GlideRecord conditions—requires JavaScript parsing after retrieval. |
| description | Description | string | Free-text test description. Often contains business context that's crucial for maintenance but not captured in test steps. |
| application | Application | reference | References sys_app for application scope. Can be empty for tests spanning multiple apps, making app-based reporting incomplete. |
| expected_duration | Expected Duration | integer | Calculated from historical run times in seconds. Gets updated after each execution, so it's unreliable for new tests or scheduling. |
| copied_from | Copied From | reference | References another sys_atf_test if this test was cloned. Creates hidden dependencies between tests that affect maintenance. |
| table | Table | string | Primary table the test operates on. May not reflect all tables touched by complex tests with multiple record interactions. |
| active | Active | boolean | Boolean active flag independent of state field. Both must be considered when determining if a test should run automatically. |
| run_as | Run As | reference | User context for test execution. References sys_user—critical for tests that validate role-based access or assignment rules. |
| abort_on_failure | Abort on Failure | boolean | Whether test suite execution stops if this test fails. Affects suite-level reporting and can mask subsequent test failures. |
| version | Version | string | Test definition version for change tracking. Increments when test steps are modified but doesn't automatically archive old versions. |
| rollback_context | Rollback Context | json | JSON data for cleaning up test changes. Contains record IDs and state info—critical for understanding test data persistence. |
| runner_status | Runner Status | choice | Current execution status: ready, running, paused, completed. May be stale if test runner crashed during execution. |
| tags | Tags | string | Comma-separated tags for test categorization. Used by test suites for dynamic test selection but prone to typos and inconsistency. |

Page: https://thesnowball.co/table/sys_atf_test

## sys_atf_test_suite (ATF Test Suite)

The `sys_atf_test_suite` table stores collections of ATF (Automated Test Framework) tests that run as coordinated groups. Owned by the Development module, it's essential for regression testing before deployments. The key thing to know: test suites execute asynchronously, so always check the `state` field before assuming completion.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Unique identifier for the test suite. Must be descriptive enough for CI/CD systems to reference programmatically. |
| description | Description | string | Free-text field for suite purpose and scope. Critical for team collaboration and maintenance documentation. |
| state | State | choice | Execution state: 'ready', 'running', 'completed'. Updates asynchronously during execution—never assume completion without polling this field. |
| active | Active | boolean | Controls suite availability for execution. Inactive suites are hidden from UI but remain scriptable via direct API calls. |
| run_type | Run Type | choice | Execution behavior: 'all' runs every test regardless of failures, 'stop_on_failure' halts suite on first test failure. |
| application | Application | reference | Reference to sys_scope. Determines application context and scope-based security for test execution. |
| created_by | Created by | reference | Reference to sys_user. Important for ownership tracking and execution permission inheritance in automated contexts. |
| abort_on_failure | Abort on Failure | boolean | When true, stops entire suite execution on first test failure. Overrides run_type behavior for critical test suites. |
| parallel_execution | Parallel Execution | boolean | Enables concurrent test execution within the suite. Can dramatically reduce execution time but may cause resource contention. |
| copy_of | Copy of | reference | Self-reference to parent suite when cloned. Useful for tracking suite templates and inheritance relationships. |
| browser_test_only | Browser Test Only | boolean | Restricts suite to browser-based tests only. Server-side tests are skipped when true, affecting execution results. |
| notes | Notes | string | Internal documentation field. Often used for execution prerequisites, known issues, or maintenance instructions. |
| sys_package | Package | reference | Reference to sys_package for update set and deployment tracking. Critical for application lifecycle management. |
| test_count | Test Count | integer | Calculated field showing number of associated tests. Updates when tests are added/removed from suite via junction table. |
| last_run | Last Run | glide_date_time | Timestamp of most recent suite execution. Used for scheduling logic and freshness validation in CI/CD pipelines. |
| last_result | Last Result | choice | Result of most recent execution: 'passed', 'failed', 'skipped'. Quick status check without joining to result tables. |

Page: https://thesnowball.co/table/sys_atf_test_suite

## sys_attachment (Attachment)

The sys_attachment table stores metadata for files attached to any ServiceNow record. Part of the Platform module, it holds file information like name, size, and content type, but not the actual binary data. The most important thing to know: it uses table_name and table_sys_id fields to reference parent records without foreign key constraints.

| Field | Label | Type | Notes |
|---|---|---|---|
| table_name | Table name | string | Name of the table containing the parent record. No foreign key constraint - can contain invalid table names. |
| table_sys_id | Table sys ID | string | sys_id of the parent record this attachment belongs to. No referential integrity - parent record may not exist. |
| file_name | File name | string | Original filename as uploaded. May contain characters that cause issues in file systems or URLs. |
| content_type | Content type | string | MIME type of the file (e.g. 'image/jpeg', 'application/pdf'). Based on file extension or HTTP headers, not actual content analysis. |
| size_bytes | Size in bytes | integer | Original file size in bytes before any compression. Doesn't reflect actual storage footprint in database. |
| size_compressed | Compressed size | integer | Compressed file size in bytes as stored in sys_attachment_doc. Often significantly smaller than size_bytes. |
| state | State | choice | Processing state: 'available', 'pending' (during upload), or 'not_available' (processing failed). Defaults to 'available'. |
| hash | Hash | string | SHA-256 hash of file content for integrity checking and duplicate detection. Calculated during upload. |
| compression | Compression | choice | Compression method used for storage: 'gzip' or 'zip'. Affects how binary data is stored in sys_attachment_doc. |
| average_image_color | Average image color | string | Hex color code of average image color, calculated for image files only. Used for UI previews and theming. |

Page: https://thesnowball.co/table/sys_attachment

## sys_attachment_doc (Attachment Document)

The sys_attachment_doc table stores binary content of attached files in chunks, owned by the Platform module. Use the GlideSysAttachment API instead of querying this table directly unless you're building custom attachment handling.

| Field | Label | Type | Notes |
|---|---|---|---|
| sys_attachment_id | Attachment | reference | References the parent sys_attachment record containing metadata. All chunks for a single file share the same attachment ID. |
| data | Data | blob | Binary content chunk. Restricted field that doesn't display in lists and can cause memory issues if accessed directly in scripts. |
| position | Position | integer | Zero-based chunk sequence number. Small files have only position 0, larger files increment from there. |
| length | Length | integer | Byte length of this chunk's binary data. Usually matches chunk size except for the final chunk of a file. |
| compressed | Compressed | boolean | Indicates if this chunk's binary data is compressed. Platform handles decompression automatically through APIs. |

Page: https://thesnowball.co/table/sys_attachment_doc

## sys_choice (Choice)

The sys_choice table stores all choice list options for every choice field across all ServiceNow tables. It's the master repository that powers dropdown menus, with each record defining a single option identified by table name + element name.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Table | string | The exact table name where this choice field exists. Must match sys_db_object.name exactly, case sensitive. |
| element | Element | string | The field name on the table that uses this choice. Combined with name field creates unique identifier for the choice field. |
| value | Value | string | The actual value stored in the database when this choice is selected. Always stored as string regardless of field type. |
| label | Label | string | The display text shown to users in the UI. Can differ from value and supports special characters and spaces. |
| sequence | Sequence | integer | Controls display order in choice lists. Lower numbers appear first. Gaps in sequence numbers are normal and don't affect functionality. |
| inactive | Inactive | boolean | When true, choice doesn't appear in UI dropdowns but can still be set programmatically and existing records retain the value. |
| language | Language | string | Language code for internationalization. Empty means base language, specific codes like 'en' or 'es' override for that locale. |
| dependent_value | Dependent value | string | Creates cascading choice dependencies. This choice only appears when the dependent field has this exact value (not label). |
| choice_set | Choice set | reference | References sys_choice_set for reusable choice collections. When populated, this choice is part of a managed set. |
| hint | Hint | string | Optional tooltip text displayed when hovering over the choice option in forms. Useful for providing additional context. |

Page: https://thesnowball.co/table/sys_choice

## sys_db_object (Table)

The `sys_db_object` table is Platform's metadata registry for every table in your instance. It stores table names, display labels, inheritance hierarchies, and configuration flags that control table behavior.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Internal table name used in GlideRecord constructors. This is the technical identifier, not the human-readable label. |
| label | Label | string | Display name shown in forms and lists. Can contain spaces and special characters unlike the name field. |
| super_class | Extends table | reference | References another sys_db_object record. Contains the table name string, not a sys_id - empty for base tables. |
| is_extendable | Can be extended | boolean | Controls UI options for creating child tables. Can be bypassed programmatically, so don't rely on it for strict governance. |
| number_ref | Auto number | reference | References sys_number table for auto-generated record numbering. Empty for most tables that don't use auto-numbering. |
| access | Application Access | string | Defines cross-scope access rules. Value 'public' allows access from any scope, while blank restricts to same scope. |
| read_access | User Role | boolean | When true, allows users with basic roles to read records. False restricts to admin+ roles for table access. |
| create_access | Create access | boolean | Controls whether users can insert new records. Checked in addition to field-level and record-level ACLs. |
| delete_access | Delete access | boolean | Allows record deletion when true. Often disabled for audit tables or core configuration data. |
| drop_access | Delete table access | boolean | Extremely restrictive - controls ability to drop the entire table structure. Almost always false. |
| ws_access | Web service access | boolean | Enables REST API and SOAP web service operations against this table when true. Required for integrations. |
| is_interface | Interface | boolean | Marks tables used as interfaces for plugin architecture. True for tables that define contracts rather than store data. |
| live_feed_enabled | Live Feed | boolean | Enables activity stream functionality. When true, record changes appear in live feed widgets and notifications. |
| caller_access | Caller Access | string | Specific access control for caller field operations. Used primarily in ITSM tables with caller relationships. |

Page: https://thesnowball.co/table/sys_db_object

## sys_dictionary (System Dictionary)

The System Dictionary (`sys_dictionary`) is the platform's metadata registry, containing one row for every field on every table in the instance. Owned by the Platform module, it's the authoritative source for table schema information and field definitions.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Table.element | string | Combines table and field names as 'table_name.field_name'. This is the unique identifier and the field you'll filter on most often. |
| element | Column name | string | The actual field name without the table prefix. Use this when building GlideRecord queries dynamically or when you need just the field name. |
| column_label | Column label | translated_field | The display name shown on forms and lists. This field is translatable and changes based on user language—don't use it for programmatic field identification. |
| internal_type | Type | choice | The actual field type (string, integer, reference, choice, etc.). This is the definitive source for field type—more reliable than inferring from other fields. |
| reference | Reference | string | For reference fields, contains the target table name. For choice fields, contains the choice list name. Check internal_type to distinguish between the two. |
| active | Active | boolean | Controls whether the field appears in forms and schema tools. Inactive fields still exist in the database and can still be queried—this just hides them from the UI. |
| read_only | Read only | boolean | Makes the field non-editable in the UI. This is a UI-level restriction and doesn't prevent programmatic updates via GlideRecord or Import Sets. |
| mandatory | Mandatory | boolean | Enforces required field validation on forms. Business Rules and server-side scripts can still save records with empty mandatory fields if they bypass form validation. |
| default_value | Default value | string | Static default value applied to new records. Dynamic defaults (like JavaScript expressions) are stored here as code strings, not the evaluated results. |
| max_length | Max length | integer | Character limit for string fields. The database enforces this limit—attempts to insert longer strings will be truncated silently or cause errors depending on the field type. |
| display | Display | boolean | Controls whether the field appears on forms by default. Fields can still be added to forms manually even when this is false. |
| virtual | Virtual | boolean | Indicates fields that don't exist as database columns (calculated fields, dot-walked references, etc.). Virtual fields can't be indexed or used in certain query contexts. |
| unique | Unique | boolean | Enforces database-level uniqueness constraint. This creates a database index and prevents duplicate values—violations will cause save operations to fail with an error. |
| choice | Choice | integer | Indicates choice field behavior: 0 = none, 1 = dropdown, 2 = suggestion, 3 = dropdown with none. The actual choice values are stored in the sys_choice table. |
| dependent | Dependent | string | For dependent choice fields, specifies the controlling field name. The choice values change based on the controlling field's value, with mappings stored in sys_choice. |
| function_definition | Function definition | string | JavaScript code for calculated fields and default value functions. This code executes server-side when the field value is needed. |
| function_field | Function field | boolean | Marks calculated fields that derive their values from function_definition code. These fields are computed dynamically and can't be directly updated. |
| reference_qual | Reference qual | string | Reference qualifier that filters available choices in reference fields. Can be static conditions or JavaScript functions that return query conditions. |

Page: https://thesnowball.co/table/sys_dictionary

## sys_email (Email Log)

The sys_email table stores all emails sent and received by the ServiceNow instance. Part of the Platform module, this table grows extremely large in production environments — always filter by type (inbound/outbound) and date ranges to avoid performance issues.

| Field | Label | Type | Notes |
|---|---|---|---|
| type | Type | choice | Direction of email: 'send' for outbound, 'receive' for inbound. Not indexed by default — add index if filtering frequently on large datasets. |
| state | State | choice | Processing status using text values: 'sent', 'ready', 'failed', 'ignored', 'draft'. Unlike most ServiceNow states, these are strings not integers. |
| recipients | Recipients | string | Comma-separated email addresses for outbound emails. For inbound emails, contains the original To: header which may include multiple addresses. |
| sender | Sender | string | Email address of sender. For outbound emails, typically the configured system sender. For inbound emails, the user's actual email address. |
| subject | Subject | string | Email subject line, often containing record numbers or reference identifiers for tracking. Limited to 255 characters. |
| body_text | Body | string | Plain text email content, limited to 8000 characters. Longer content gets silently truncated — use attachments for large content. |
| body | Body HTML | string | HTML version of email content when available. Also limited to 8000 characters, truncated without warning if exceeded. |
| target_table | Target Table | string | Table name (like 'incident', 'sc_request') that this email relates to. Used with target field to link emails to specific records. |
| target | Target | string | Sys_id of the related record in target_table. Stores as string, not reference — cannot dot-walk, must use getValue() for comparisons. |
| message_id | Message ID | string | SMTP Message-ID header for tracking and preventing duplicates. Critical for email threading and reply matching. |
| in_reply_to | In Reply To | string | Message-ID of email this is replying to. Used for threading emails and associating responses with original notifications. |
| cc_list | CC | string | Comma-separated CC recipients. May be empty even if original email had CC addresses due to privacy or processing rules. |
| bcc_list | BCC | string | Comma-separated BCC recipients, typically populated only for outbound emails since inbound BCC headers are usually stripped. |
| user_id | User | reference | Reference to sys_user record. For outbound emails, the user who triggered the notification. For inbound, the identified sender or empty if not recognized. |
| mailbox | Mailbox | string | Email account or mailbox used for processing. References configuration in sys_email_account for SMTP/IMAP settings. |
| size | Size | integer | Email size in bytes including headers and body. Does not include attachments, which are stored separately in sys_attachment. |
| error_string | Error String | string | Error message for failed emails. Contains SMTP errors, authentication failures, or processing exceptions. Only populated when state is 'failed'. |
| notification | Notification | reference | Reference to sys_email_notification record that generated this outbound email. Empty for inbound emails or manually sent messages. |
| priority | Priority | choice | Email priority level: 1 (high), 3 (normal), 5 (low). Affects processing order in email queue but not guaranteed delivery priority. |
| watermark | Watermark | string | Unique identifier added to outbound emails for reply tracking. ServiceNow uses this to match inbound replies to original records. |

Page: https://thesnowball.co/table/sys_email

## sys_hub_action_type_base (Action)

The `sys_hub_action_type_base` table stores Flow Designer action definitions — both custom and out-of-box reusable actions that flows can execute. Owned by Flow Designer, the key thing to know is that records here define action metadata and interface, not execution instances.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Internal action name used in flow references. Must be unique within scope and cannot contain spaces or special characters. |
| label | Label | string | Display name shown in Flow Designer action picker. Can contain spaces and special characters unlike the name field. |
| state | State | choice | Action lifecycle state: 'published' (available for use), 'draft' (under development), 'retired' (deprecated but not deleted). |
| type | Type | choice | Action implementation type: 'script', 'subflow', 'rest', etc. Determines which child table contains additional configuration. |
| category | Category | reference | References sys_hub_category for Flow Designer organization. Affects where the action appears in the action picker tree. |
| inputs | Inputs | json | JSON schema defining action input parameters. Used by Flow Designer to generate input forms and validate data types. |
| outputs | Outputs | json | JSON schema defining action output values. Flow Designer uses this to provide data pills for subsequent flow steps. |
| annotation | Annotation | xml | Action description and help text in XML format. Contains rich text formatting and tooltips shown in Flow Designer. |
| sys_scope | Application | reference | Scoped application that owns this action. Determines visibility and upgrade behavior across application boundaries. |
| sys_package | Package | reference | Update set package for deployment. Critical for custom actions — missing package can cause actions to disappear during upgrades. |
| active | Active | boolean | Administrative override for action availability. Even published actions won't appear in picker if inactive. |
| latest | Latest | boolean | Indicates if this is the current version of the action. ServiceNow uses this internally for action evolution. |
| copyable | Copyable | boolean | Whether users can create copies of this action as starting points for custom actions. Typically true for templates. |
| deletable | Deletable | boolean | Whether this action can be deleted from the system. ServiceNow out-of-box actions are typically not deletable. |
| access | Access | choice | Access level for action usage: 'public' (all scopes), 'restricted' (same scope only). Affects cross-scope flow development. |
| sys_class_name | Class Name | string | Table name for polymorphic queries. Always 'sys_hub_action_type_base' for base records, child table names for specific types. |

Page: https://thesnowball.co/table/sys_hub_action_type_base

## sys_hub_flow (Flow)

The `sys_hub_flow` table stores Flow Designer flows in the Flow Designer module. Each record represents a complete flow definition with its trigger configuration, active state, and internal JSON graph structure. While not designed for direct scripting manipulation, it's essential for flow inventory, reporting, and administrative queries.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Flow display name shown in Flow Designer. Not unique across scopes — multiple flows can have the same name in different applications. |
| active | Active | boolean | Controls whether the flow can execute. Setting to false prevents new executions but doesn't stop running instances. |
| trigger_type | Trigger Type | string | Internal identifier for trigger mechanism like 'record.inserted', 'schedule', 'application.operation'. Use exact internal values in queries, not UI display names. |
| graph | Graph | string | Complete flow definition as JSON. Can be 50KB+ per record. Avoid querying unless specifically needed due to performance impact. |
| description | Description | string | User-provided flow description. Often empty despite being visible in the UI — check for null/empty values in queries. |
| sys_scope | Application | reference | Reference to sys_scope table. Use this for application-based queries, not sys_package which points to the update set when created. |
| copied_from | Copied from | reference | Reference to original flow when this is a copy. Chain can be multiple levels deep — references the ultimate source, not immediate parent. |
| run_as | Run As | reference | sys_user reference defining execution context. Empty means run as triggering user. Critical for understanding flow permissions and access. |
| category | Category | string | Optional categorization field. Often null but useful for organizing flows in large environments when populated. |
| template | Template | boolean | Marks flows designed as templates for copying. Template flows are typically inactive but contain reusable patterns. |
| condition | Condition | string | Encoded condition string for record-triggered flows. Contains table and field filter logic — not human-readable but essential for dependency analysis. |
| schedule | Schedule | string | Schedule configuration for scheduled flows. Contains repeat interval and timing data in internal format. |
| application_operation | Application Operation | string | Operation identifier for application-triggered flows. Links to specific ServiceNow operations that can invoke the flow. |
| latest_instance | Latest Instance | reference | Reference to most recent execution in sys_hub_flow_instance. Auto-maintained but can be null for never-executed flows. |
| flow_level | Flow Level | choice | Execution priority level. Higher levels get processing preference but require additional licensing in some environments. |

Page: https://thesnowball.co/table/sys_hub_flow

## sys_hub_subflow (Subflow)

The sys_hub_subflow table stores reusable Flow Designer subflows that can be called from flows or other subflows. Owned by the Flow Designer module, this table enables component reusability across automation workflows. The most important thing to know: always check the `active` field and `category` when querying, as inactive subflows won't execute even if referenced.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | The subflow's display name. Must be unique within the scope and is used for subflow selection in Flow Designer. |
| active | Active | boolean | Controls subflow availability for execution. Inactive subflows cause runtime failures in flows that reference them. |
| category | Category | string | Groups subflows for organization. This is a free-text field, not a choice list, so typos create new categories. |
| description | Description | string | Long text description of subflow functionality. Avoid querying this field directly due to performance implications. |
| sys_scope | Application | reference | References sys_scope table. Determines subflow visibility across applications and affects cross-scope subflow calls. |
| copied_from | Copied from | reference | Self-reference for subflow versioning. Links to the original subflow when creating copies, forming a version chain. |
| inputs | Inputs | json | JSON definition of input parameters. Contains parameter names, types, and constraints for subflow execution. |
| outputs | Outputs | json | JSON definition of output parameters. Defines what data the subflow returns to calling flows or subflows. |
| flow_designer_type | Flow Designer Type | string | Always 'subflow' for this table. Inherited from parent sys_hub_flow table to distinguish from regular flows. |
| template | Template | reference | References template definition if subflow was created from a template. Null for custom-built subflows. |
| protect_inputs | Protect Inputs | boolean | When true, prevents modification of input parameter values in flows that use this subflow. |
| run_as | Run As | choice | Execution context: 'user' (calling user's context) or 'system' (elevated system context). Affects permissions during execution. |
| published_version | Published Version | string | Version identifier for published subflows. Used to track subflow versions across instances and deployments. |
| api_name | API Name | string | Unique identifier for REST API access. Generated automatically but can be customized for better API integration. |
| internal | Internal | boolean | Marks system-created subflows. Internal subflows may have different upgrade behavior and visibility restrictions. |

Page: https://thesnowball.co/table/sys_hub_subflow

## sys_import_set (Import Set)

The sys_import_set table tracks import operations from external systems into ServiceNow. Part of the Integration module, it creates a record for each import session while actual imported data goes into dynamically generated import set tables. Critical for monitoring data loads and debugging failed imports.

| Field | Label | Type | Notes |
|---|---|---|---|
| state | State | choice | Current processing state: loading, loaded, processing, processed, or cancelled. Transforms can only run when state equals 'loaded'. |
| table_name | Table name | string | Name of the dynamically created import table without the u_ prefix. Must prepend u_ when querying the actual import data table. |
| name | Name | string | Display name for the import set. Defaults to the data source name but can be customized for manual imports. |
| data_source | Data Source | reference | References sys_data_source that defines the import configuration. Null for one-time manual imports via UI or web service. |
| row_count | Row count | integer | Number of records imported. Updates asynchronously during loading—don't rely on it for real-time counts. |
| run_time | Run time | integer | Import duration in milliseconds. Displays in human-readable format but stores as integer for calculations. |
| started_on | Started on | glide_date_time | Timestamp when import began loading data. Critical for performance monitoring and timeout troubleshooting. |
| completed_on | Completed on | glide_date_time | Timestamp when import reached final state. Used to calculate total processing time including transforms. |
| source_table | Source table | string | Name of the target table where transformed data will be inserted or updated. Empty for staging-only imports. |
| total_rows_processed | Total rows processed | integer | Count of rows that completed transform processing. May differ from row_count if transforms skip or reject records. |
| total_rows_ignored | Total rows ignored | integer | Count of rows skipped during transform due to conditions or errors. Essential for data quality monitoring. |
| total_rows_inserted | Total rows inserted | integer | Count of new records created in target table. Combined with updated count shows total impact. |
| total_rows_updated | Total rows updated | integer | Count of existing records modified in target table. Zero for insert-only transforms. |
| schedule_id | Schedule | reference | References sys_trigger for scheduled imports. Null for manual imports or one-time loads. |
| description | Description | string | Optional description of the import purpose. Helpful for distinguishing similar data sources in monitoring. |
| active | Active | boolean | Whether the import set is available for processing. Inactive sets cannot be transformed or queried normally. |
| delete_after_processing | Delete after processing | boolean | When true, import set and its table are automatically cleaned up after successful transform completion. |

Page: https://thesnowball.co/table/sys_import_set

## sys_notification (Notification)

The sys_notification table stores email notification configuration records in the Platform module. These records define when and how notifications are sent based on events. The key thing developers need to know: notifications fire based on complex condition logic that evaluates against the triggering record's data.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Human-readable notification identifier. Must be unique within scope and commonly follows naming convention like 'Incident Assignment Notification'. |
| table | Table | string | Target table name where records changes trigger this notification. Uses actual table name like 'incident' not display name, and applies to child tables via inheritance. |
| when | When to Send | choice | Trigger event type: 'insert', 'update', 'delete'. Multiple values stored comma-separated but 'query' option is deprecated and should be avoided. |
| filter | Condition | conditions | Encoded query string defining when notification should fire. Uses same syntax as list filters but doesn't validate field existence - invalid filters fail silently. |
| condition | Advanced Condition | script_plain | JavaScript condition evaluated against current record. Executes in separate scope from Business Rules with limited GlideRecord functionality and different current.getValue() behavior. |
| active | Active | boolean | Controls whether notification processes record changes. Cache delays mean setting to false doesn't immediately stop processing across all application nodes. |
| order | Order | integer | Execution sequence when multiple notifications have identical conditions. Lower numbers execute first but most notifications should use standard value of 100. |
| category | Category | string | Organizational grouping for notifications like 'workflow' or 'approval'. Used primarily for administrative organization and reporting. |
| collection | Collection | string | Alternative name for table field, maintained for backward compatibility. Modern notifications should use table field instead. |
| weight | Weight | integer | Priority factor affecting notification processing order. Higher weights indicate higher priority but rarely used in practice. |
| message | Message HTML | string | Direct HTML message content for notifications not using separate email templates. Supports variable substitution using ${field_name} syntax. |
| subject | Subject | string | Email subject line supporting variable substitution. Commonly uses ${number} or ${short_description} to identify the triggering record. |
| recipients | Recipients | string | Comma-separated list of email addresses or user sys_ids for direct notification delivery. Most notifications use email devices instead for dynamic recipient logic. |
| description | Description | string | Documentation field explaining notification purpose and business logic. Critical for maintenance as condition logic can be complex and non-obvious. |
| sys_domain | Domain | domain_id | Domain separation identifier restricting notification visibility and execution. Global domain notifications (empty value) are visible across all domains. |
| force_delivery | Force delivery | boolean | Bypasses user notification preferences and subscription settings to guarantee delivery. Use sparingly as it overrides user privacy controls. |
| notification_filter | User notification filter | choice | Defines which users receive notifications based on relationship to record: 'event.parm1', 'affected_user', 'caller', or custom field references. |
| digest | Digest | choice | Groups multiple notifications into summary emails: 'never', 'daily', 'weekly'. Reduces email volume but delays notification delivery. |
| mandatory | Mandatory | boolean | Prevents users from unsubscribing from this notification type. Reserved for critical business notifications like security alerts or compliance requirements. |

Page: https://thesnowball.co/table/sys_notification

## sys_portal (Service Portal)

The sys_portal table stores Service Portal configuration records in the Service Portal module. Each record defines a complete portal instance with its URL suffix, theme, homepage, and CSS variables — the foundation for all portal customization.

| Field | Label | Type | Notes |
|---|---|---|---|
| title | Title | string | Portal display name shown in lists and breadcrumbs. Not used for URL generation. |
| url_suffix | URL Suffix | string | Defines the portal URL path after /sp/. Empty value creates the default portal at /sp/. |
| homepage | Homepage | reference | References sp_page table for the default landing page. Can reference pages from different portals. |
| theme | Theme | reference | References sp_theme table for visual styling. Theme changes cascade immediately to all portal pages. |
| css_variables | CSS Variables | string | Stores JSON object of CSS variable overrides. Invalid JSON silently breaks portal rendering. |
| active | Active | boolean | Controls portal availability but doesn't block direct URL access — requires Business Rules for enforcement. |
| quick_start_user | Quick Start User | reference | References sys_user table for portal designer preview context. Determines whose permissions are used in designer. |
| knowledge_base | Knowledge Base | reference | References kb_knowledge_base table for portal's knowledge articles. Filters knowledge searches to this base. |
| logo | Logo | user_image | Portal logo image attachment. Overrides theme logo when specified. |
| short_description | Short Description | string | Portal purpose description for administrative documentation. Not displayed to portal users. |
| login_page | Login Page | reference | References sp_page table for custom login page. Falls back to system default when empty. |
| enable_rtl | Enable RTL | boolean | Enables right-to-left text direction support for Arabic, Hebrew, and other RTL languages. |
| sc_catalog | Service Catalog | reference | References sc_catalog table for default catalog. Limits catalog visibility in this portal. |
| default_language | Default Language | string | ISO language code for portal's default language. Affects initial page load before user preferences. |

Page: https://thesnowball.co/table/sys_portal

## sys_properties (System Property)

The sys_properties table stores platform configuration as key-value pairs accessed via gs.getProperty() and gs.setProperty(). Owned by the Platform module, this table controls everything from timeouts to feature flags across your instance.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | The property key used in gs.getProperty(). Must be unique and should follow naming conventions like 'company.module.setting'. |
| value | Value | string | The property value as a string. Limited to 4,000 characters and always returned as string from gs.getProperty() regardless of content. |
| description | Description | string | Human-readable description of what this property controls. Critical for maintenance since property purposes aren't obvious from names alone. |
| type | Type | choice | Data type hint (string, boolean, integer, etc.). Purely documentational—all values are stored and returned as strings. |
| choices | Choices | string | Comma-separated list of valid values when type is 'choice'. Used by the UI for dropdown validation but not enforced programmatically. |
| suffix | Suffix | string | Optional suffix appended to the name for display purposes. Helps organize related properties in the System Properties list. |
| read_roles | Read roles | string | Comma-separated list of roles required to read this property. Empty means all users can read via gs.getProperty(). |
| write_roles | Write roles | string | Comma-separated list of roles required to modify this property. Defaults to 'admin' if empty when security is enforced. |
| ignore_cache | Ignore cache | boolean | Forces fresh database read on every gs.getProperty() call instead of using cached value. Rarely needed and impacts performance. |
| is_private | Private | boolean | Hides property from System Properties list for non-admin users. The value is still readable via gs.getProperty() if role permits. |
| status | Status | choice | Lifecycle status of the property. 'Available' properties are active, others are filtered from normal operation. |

Page: https://thesnowball.co/table/sys_properties

## sys_report (Report)

The `sys_report` table stores report definitions including filter conditions, grouping configuration, and chart visualization settings. Part of the Reporting module, it defines how data gets aggregated and displayed in reports and dashboards. The most important thing to know: report filters are stored as XML in the `filter` field, not as readable GlideRecord conditions.

| Field | Label | Type | Notes |
|---|---|---|---|
| title | Title | string | Display name of the report. This appears in report lists and is searchable by end users—not guaranteed to be unique. |
| table | Table | string | Name of the table this report queries against. Stored as string, not reference, so no referential integrity checking. |
| filter | Filter | string | Report filter conditions stored as encoded XML. Cannot be queried directly with contains() or other string operations—requires XML parsing. |
| report_type | Type | choice | Type of report: 'table' (list), 'chart' (chart), or 'pivot' (pivot table). Determines which other configuration fields are relevant. |
| chart_type | Chart type | choice | Visualization type for chart reports: bar, line, pie, etc. Ignored for list reports but can still contain stale values from type changes. |
| field | Group by | string | Primary field for grouping/aggregation in charts and pivot tables. Field name as string—validate it exists on target table. |
| list_field_name | Column field | string | Field used for pivot table columns. Critical for pivot reports but meaningless for other types—check report_type before using. |
| sum_field | Aggregate field | string | Field to sum/count/average in aggregated reports. Can be empty for simple count aggregations. |
| aggregate_type | Aggregate type | choice | How to aggregate the sum_field: COUNT, SUM, AVG, MIN, MAX. COUNT is most common and doesn't require sum_field to be set. |
| order_by | Order by | string | Field name for sorting results. Can include 'DESC' suffix for descending order, otherwise assumes ascending. |
| order_by_desc | Descending | boolean | Whether to sort in descending order. Works with order_by field—both mechanisms exist for backward compatibility. |
| is_published | Published | boolean | Whether report is published for sharing. Unpublished reports are only visible to the creator and report admins. |
| roles | Roles | string | Comma-separated list of role names that can view this report. Empty means available to all users who can access the module. |
| report_source | Report source | string | Tracks how the report was created: 'wizard', 'list_v2', 'import', etc. Useful for auditing report creation patterns. |
| sys_domain | Domain | reference | Domain separation field. Reports inherit domain restrictions and can only query tables in the same domain hierarchy. |

Page: https://thesnowball.co/table/sys_report

## sys_rest_message (REST Message)

The sys_rest_message table stores outbound REST API integration configurations managed in the Integration module. Developers script against this table when dynamically creating or modifying REST message definitions that work with the RESTMessageV2 class.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Unique identifier used in RESTMessageV2 constructor. Must be unique and case-sensitive across all REST messages. |
| endpoint | Endpoint | string | Base URL for the REST service. Can contain variable substitutions like ${instance} that are resolved at runtime. |
| description | Description | string | Documentation for the REST message purpose and usage. Critical for maintaining enterprise integrations. |
| authentication_type | Authentication Type | choice | Defines auth method: inherit_from_parent, basic, oauth2, or no_authentication. Must match corresponding auth_profile_id type. |
| auth_profile_id | Authentication Profile | reference | References specific auth profile table based on authentication_type. Points to sys_auth_profile_basic, sys_auth_profile_oauth2, etc. |
| use_mid_server | Use MID Server | boolean | Routes REST calls through MID Server instead of direct ServiceNow outbound. Required for internal network endpoints. |
| mid_server | MID Server | reference | References ecc_agent table for specific MID Server selection. Only relevant when use_mid_server is true. |
| active | Active | boolean | Controls whether REST message can be executed. Inactive messages will cause RESTMessageV2 constructor to fail. |
| accessible_from | Accessible From | choice | Scoped application access control: all, package_private, or this_application_scope_only. Affects cross-scope usage. |
| application | Application | reference | References sys_app table for scoped application ownership. Determines default access permissions and update set scope. |
| rest_endpoint | REST Endpoint | string | Alternative endpoint configuration that can override the primary endpoint field in specific contexts. |
| protocol_name | Protocol Name | choice | HTTP protocol version preference. Usually 'rest' but can affect header handling and connection behavior. |
| lock_version | Lock Version | integer | Version control for concurrent updates. Prevents conflicts when multiple developers modify the same REST message. |
| default_request_headers | Default Request Headers | string | JSON string of headers applied to all HTTP methods. Parsed at runtime and merged with method-specific headers. |
| use_basic_auth | Use Basic Authentication | boolean | Legacy field for basic auth. Superseded by authentication_type and auth_profile_id but still affects some configurations. |

Page: https://thesnowball.co/table/sys_rest_message

## sys_script (Business Rule)

The `sys_script` table stores Business Rule definitions - server-side scripts that execute on database operations. Owned by the System Definition module, this table defines when, where, and what code runs during record lifecycle events.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | The display name of the Business Rule. Must be unique within the same application scope. |
| collection | Table | string | The table name this Business Rule executes against. Stored as a string (e.g., 'incident'), not a reference to sys_db_object. |
| active | Active | boolean | Controls whether the Business Rule executes. Inactive rules are completely ignored by the platform and don't impact performance. |
| when | When | choice | Execution timing using bitwise values: before=1, after=2, async=4, display=8. Multiple timings are OR'd together (e.g., before+after=3). |
| order | Order | integer | Execution sequence within the same timing. Lower numbers execute first, but before rules always run before after rules regardless of order. |
| script | Script | script | The JavaScript code to execute. Contains queries against this field are extremely slow and should be avoided in production. |
| condition | Condition | conditions | Encoded condition string that determines when the rule executes. Simple conditions are readable, but advanced conditions require parsing. |
| filter_condition | Filter Condition | string | Additional JavaScript condition evaluated before script execution. Provides more flexibility than the encoded condition field. |
| abort_action | Abort Action | boolean | When true, allows the Business Rule to prevent database operations by calling current.setAbortAction(true) in before rules. |
| advanced | Advanced | boolean | Enables advanced scripting features and removes some platform guardrails. Should be used sparingly for performance reasons. |
| rest_service | REST Service | boolean | When true, the rule executes for REST API operations. When false, it's considered 'Global' and executes for all database operations. |
| is_rest | Execute on REST | boolean | Controls execution for REST operations. Opposite behavior from rest_service - when false, rule executes for all operations including REST. |
| template | Template | reference | References sys_template for mail script Business Rules. Links the rule to notification templates for email processing. |
| sys_domain | Domain | domain_id | Domain scope for the Business Rule. Controls visibility and execution based on the user's domain in multi-domain instances. |
| role_conditions | Role Conditions | string | Comma-separated list of roles required for the rule to execute. Empty means no role restrictions apply. |
| add_message | Add Message | boolean | When true, allows the Business Rule to add messages to the user interface using gs.addInfoMessage() and similar methods. |
| priority | Priority | integer | Execution priority within the same order value. Higher priority rules execute first when order values are equal. |
| sys_class_name | Class | string | Always 'sys_script' for Business Rules. Used internally for metadata classification and inheritance. |
| sys_scope | Application | reference | References sys_scope to indicate which application owns this Business Rule. Critical for scoped application boundaries. |

Page: https://thesnowball.co/table/sys_script

## sys_script_client (Client Script)

The sys_script_client table stores Client Scripts—browser-side JavaScript that runs on forms during onLoad, onChange, onSubmit, and onCellEdit events. Owned by the Development module, these scripts control form behavior and field interactions in real-time.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Human-readable script name. Must be unique per table—duplicates cause form loading issues. |
| table | Table | string | Internal table name where this script runs. Cannot be changed after creation without breaking form behavior. |
| type | Type | choice | Script execution timing: onLoad, onChange, onSubmit, onCellEdit. Determines available g_form methods and when the script fires. |
| script | Script | script_plain | The actual JavaScript code. Has separate ACL protection—requires explicit field access to read or modify. |
| active | Active | boolean | Controls script execution. Inactive scripts still load in Studio, creating confusion about what's actually running. |
| global | Global | boolean | Runs on all tables when true, but with limited g_form API access. Cannot use getReference() or advanced methods. |
| condition | Condition | conditions | Server-side condition evaluated before loading the script. Complex conditions slow form loading since they run server-side first. |
| field | Field name | string | Target field for onChange scripts. Must be exact field name—display labels don't work and cause silent failures. |
| ui_type | UI Type | choice | Execution context: 0=Desktop, 10=Mobile, All=Both. Wrong setting means scripts won't run on mobile devices. |
| order | Order | integer | Execution sequence for multiple scripts on same field/event. Lower numbers run first, but relying on order creates fragile code. |
| view | View | string | Specific form view where script runs. Empty means all views—use sparingly since it's hard to troubleshoot. |
| inherited | Inherited | boolean | Read-only flag indicating script comes from parent table. Cannot be directly modified—controlled by table inheritance. |
| applies_to | Applies to | string | Internal field storing table inheritance data. Automatically maintained by platform—manual changes break script loading. |
| description | Description | string | Documentation field that's often empty in production. Critical for maintenance since Client Script code lacks inline comments. |
| messages | Messages | string | UI messages displayed by the script. Stored as comma-separated keys that reference sys_ui_message records. |

Page: https://thesnowball.co/table/sys_script_client

## sys_script_include (Script Include)

The sys_script_include table stores reusable server-side JavaScript libraries that can be called from Business Rules, other Script Includes, REST APIs, and Flow Designer. It's owned by the Development module. The critical gotcha: the api field must be true for the Script Include to be callable from other server-side scripts.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | The unique identifier for the Script Include used in JavaScript instantiation. Must follow JavaScript naming conventions and be unique within scope. |
| script | Script | script | The JavaScript code content. Limited to 64KB and must define the constructor function matching the name field for proper instantiation. |
| api | Accessible from | choice | Controls server-side accessibility. Must be 'server' (true) for the Script Include to be callable from Business Rules and other server scripts. |
| access | Access | choice | Defines availability scope: 'public' loads at startup and caches globally, 'package_private' restricts to application scope, 'private' loads on-demand. |
| active | Active | boolean | Controls whether the Script Include is available for use. Cached instances may persist briefly after deactivation until cache refresh. |
| client_callable | Client callable | boolean | Allows Ajax calls from client-side scripts. Only affects GlideAjax accessibility, not server-side Script Include usage. |
| description | Description | string | Functional description of the Script Include purpose. Commonly searched for documentation generation and code analysis tools. |
| sys_scope | Application | reference | References sys_scope table determining application boundary. Private scope Script Includes cannot call Script Includes from other private scopes. |
| sys_package | Package | reference | References sys_package for update set tracking. Critical for deployment management and determining which update set contains the Script Include. |
| protection_policy | Protection policy | reference | References protection policy for upgrade-safe customization. Controls whether upgrades overwrite local changes to out-of-box Script Includes. |
| sys_policy | Domain | string | Domain separation value inherited from sys_scope. Affects visibility in multi-domain instances where Script Includes respect domain boundaries. |

Page: https://thesnowball.co/table/sys_script_include

## sys_transform_entry (Field Map)

The sys_transform_entry table stores individual field mappings within Transform Maps in the Integration module. Each record defines how a source column maps to a target field, with optional coalesce behavior and transformation scripts.

| Field | Label | Type | Notes |
|---|---|---|---|
| map | Transform Map | reference | References sys_transform_map. Always include in queries for performance. Defines which transform map owns this field mapping. |
| source_field | Source Field | string | Column name from Import Set table. Must exactly match source column including case. Empty value creates constant mappings using target_field value. |
| target_field | Target Field | string | Field name in target table. For constant mappings without source_field, this stores the literal value to insert. |
| script | Script | script | JavaScript transformation code. Executes in transform map scope with 'source' and 'target' variables available. Return value populates target field. |
| coalesce | Coalesce | boolean | Controls update behavior: true updates existing records, false only inserts new records. Empty value inherits from transform map settings. |
| active | Active | boolean | Enables or disables this field mapping. Defaults to true. Inactive entries remain visible in UI but don't process during transforms. |
| order | Order | integer | Execution sequence within transform map. Lower numbers execute first. Critical for dependent field mappings and reference resolution. |
| source_table | Source Table | string | Import Set table name. Usually populated automatically from parent transform map but can override for complex multi-table scenarios. |
| target_table | Target Table | string | ServiceNow table receiving the data. Inherited from transform map but stored here for query optimization and reporting. |
| use_source_script | Use Source Script | boolean | When true, ignores source_field and uses script to determine source value. Enables complex source data processing and calculations. |
| choice_action | Choice Action | choice | Behavior when choice values don't match: ignore, create, or reject. Only applies to choice fields in target table. |
| reference_action | Reference Action | choice | Behavior when reference values don't resolve: ignore, create, or reject. Controls foreign key handling during transformation. |

Page: https://thesnowball.co/table/sys_transform_entry

## sys_transform_map (Transform Map)

The `sys_transform_map` table defines how data flows from import set tables to target tables during data integration. Owned by the Integration module, each record represents a complete transformation configuration that maps source columns to destination fields with optional transformation scripts.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Display name of the transform map. Must be unique within the instance and commonly follows naming patterns like 'Import User Data from LDAP'. |
| source_table | Source table | string | Name of the import set table (must start with 'u_'). This is the staging table where raw data lands before transformation. |
| target_table | Target table | string | ServiceNow table where transformed records will be created or updated. Can be any valid table name like 'incident' or 'cmdb_ci_server'. |
| active | Active | boolean | Controls whether this transform map executes during import processing. Inactive maps are skipped but remain visible in the UI. |
| run_business_rules | Run business rules | boolean | When true, Business Rules on the target table execute for each transformed record. Can significantly impact performance and cause unexpected side effects. |
| coalesce_empty_fields | Coalesce empty fields | boolean | Determines how empty strings are handled during coalescing. When true, empty strings are treated as NULL for matching purposes. |
| update_existing | Update existing records | boolean | Controls whether transformation can update existing records or only create new ones. Requires coalesce fields to be defined for updates. |
| on_start | On Start Script | script | JavaScript that executes once at the beginning of the transform process, before any individual records are processed. |
| on_before | On Before Script | script | JavaScript that executes for each source record before the target record is created/updated. Has access to 'source' and 'target' variables. |
| on_after | On After Script | script | JavaScript that executes for each source record after the target record is saved. Useful for creating related records or logging. |
| on_complete | On Complete Script | script | JavaScript that executes once after all records in the import set have been processed, regardless of success or failure. |
| audit_table | Audit table | string | Optional table name for storing transformation audit records. Rarely used but allows custom logging of transform activities. |
| description | Description | string | Free-text description of the transform map's purpose and any special handling notes. Critical for documentation in complex integrations. |
| script | Script | script | Legacy script field that executes during transformation. Deprecated in favor of the specific on_start, on_before, on_after event scripts. |

Page: https://thesnowball.co/table/sys_transform_map

## sys_trigger (Scheduled Job)

The sys_trigger table stores scheduled jobs in ServiceNow, owned by the Platform module. The critical thing to know: records persist after execution with state tracking, so always filter by active status unless you want historical data.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Job Name | string | Display name for the scheduled job. Not enforced as unique, so multiple jobs can have identical names. |
| active | Active | boolean | Controls whether the job is eligible for execution. True doesn't mean running — check state field for actual execution status. |
| state | State | choice | Current execution state: 0=Ready, 1=Running, 2=Complete, 3=Cancelled. Running state persists until job completes or fails. |
| script | Script | script | JavaScript code executed when job runs. Large text field without indexing — avoid queries that filter on script content. |
| conditional_script | Condition | script | JavaScript evaluated before execution to determine if job should run. Must return boolean true for job to proceed. |
| next_action | Next Run | glide_date_time | When the job will execute next. Uses server timezone, not user timezone. Updated automatically after each execution. |
| trigger_type | Type | choice | Execution pattern: 0=Run once, 1=Repeat. One-time jobs stay active after completion until manually disabled. |
| cron_expression | Repeat | string | Standard cron expression for recurring jobs. Invalid syntax fails silently at execution time, not during save. |
| run_as | Run As | reference | User context for script execution. Job fails with permission errors if referenced user becomes inactive. |
| job_context | Job Context | string | Execution context identifier used internally by scheduler. Blank for user-created jobs, populated for system jobs. |
| run_start | Started | glide_date_time | Timestamp when current or last execution began. Useful for calculating job runtime and detecting stuck jobs. |
| run_time | Run Duration | integer | Execution time in milliseconds for last completed run. Zero for jobs that never completed successfully. |
| error_code | Error Code | choice | Numeric error code from last execution attempt. 0=Success, non-zero values indicate various failure conditions. |
| error_message | Error Message | string | Text description of last execution error. Truncated to field length — check syslog table for complete error details. |
| run_count | Run Count | integer | Total number of times job has executed since creation. Increments on each attempt, regardless of success or failure. |
| time_zone | Time Zone | string | Timezone for cron expression evaluation. Defaults to system timezone if blank. Changes affect next_action calculation. |
| application | Application | reference | Application scope that owns the job. Affects script execution context and available APIs within the job script. |
| claimed_by | Claimed By | string | Node identifier in clustered environments showing which node is executing the job. Blank when not running. |

Page: https://thesnowball.co/table/sys_trigger

## sys_ui_action (UI Action)

The sys_ui_action table stores form buttons, related links, and context menu items across ServiceNow. Owned by the Development module, these records define both UI elements and their associated client-side or server-side scripts. Critical gotcha: UI Actions with client scripts execute before the form submits, while server-side actions run after form submission.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Internal identifier for the UI Action, used in scripts and references. Must be unique per table and automatically becomes the button's DOM element ID. |
| table | Table | string | Table name where this UI Action appears. Empty value creates a global action that appears on all tables unless overridden by table-specific actions. |
| action_name | Action name | string | Defines the form submission action for form buttons. Common values include 'insert', 'update', 'delete'. Only applies when form_style is true. |
| active | Active | boolean | Controls whether the UI Action appears in any interface. Inactive actions are completely hidden but preserve their configuration for future reactivation. |
| client | Client | boolean | Determines execution context: true for client-side JavaScript (immediate execution), false for server-side (executes after form submission). Cannot be changed after creation. |
| condition | Condition | string | Server-side JavaScript that determines UI Action visibility. Evaluates in limited context without access to client-side variables like g_form. |
| form_style | Form button | boolean | Shows the action as a form submit button (Save, Update, etc). Form style actions trigger form submission and can change record state. |
| list_style | List banner button | boolean | Displays the action in the list banner above the list view. List actions typically operate on selected records or provide list-wide functionality. |
| list_choice | List choice | boolean | Adds the action to the context menu (right-click) for individual list rows. Choice actions operate on single records within list views. |
| form_link | Form link | boolean | Shows the action as a related link in the form's Related Links section. Form links typically navigate to related records or external resources. |
| form_context_menu | Form context menu | boolean | Includes the action in the form's right-click context menu. Context menu actions provide quick access to common operations without cluttering the button bar. |
| script | Script | string | JavaScript code that executes when the action is triggered. 8000 character limit; longer scripts should use Script Includes for maintainability. |
| order | Order | integer | Controls display sequence within the same action type (form buttons, list buttons, etc). Lower numbers appear first, but mixed action types follow platform ordering rules. |
| show_insert | Show on insert | boolean | Controls visibility on new record forms. False hides the action during record creation but shows it on existing records. |
| show_update | Show on update | boolean | Controls visibility on existing record forms. False hides the action when editing saved records but shows it during initial creation. |
| onclick | Onclick | string | Client-side JavaScript that executes before the main script. Primarily used for form validation or confirmation dialogs that may prevent action execution. |
| view | View | reference | Reference to sys_ui_view that restricts action visibility to specific form views. Empty value shows the action in all views for the target table. |
| ui_type | UI Type | choice | Defines action appearance and behavior. Values include '0' (button), '1' (link), '11' (tab). Controls visual styling and interaction patterns. |
| hint | Hint | string | Tooltip text that appears when users hover over the action. Supports HTML formatting and can include dynamic content through client-side evaluation. |

Page: https://thesnowball.co/table/sys_ui_action

## sys_ui_policy (UI Policy)

The sys_ui_policy table defines UI Policies that control form field behavior — visibility, mandatory state, and read-only properties — applied by the UI Policy engine in order. Most developers query this table when building form customizations or debugging field behavior issues.

| Field | Label | Type | Notes |
|---|---|---|---|
| table | Table | string | The exact table name where this policy applies. Extended tables inherit parent policies unless overridden. |
| short_description | Short description | string | Human-readable policy name. Critical for maintenance since technical names aren't auto-generated. |
| active | Active | boolean | Controls whether this policy executes on forms. Inactive policies still appear in Studio lists. |
| conditions | Conditions | conditions | Encoded condition string that determines when this policy executes. Empty conditions always evaluate to true. |
| order | Order | integer | Execution sequence number. Lower values execute first. ServiceNow doesn't auto-renumber when inserting policies. |
| applies_to | Applies to | choice | Controls where policy executes: form views, list views, or both. Default is form views only. |
| on_load | On load | boolean | Executes policy when form first loads. Essential for initial field state setup. |
| catalog_item | Catalog Item | reference | Restricts policy to specific catalog item forms. Only applies to sc_req_item and sc_cart_item records. |
| catalog_category | Catalog Category | reference | Restricts policy to catalog items within a specific category. Broader scope than catalog_item. |
| view | View | string | Limits policy to specific form view. Empty means all views. Common values: 'default', 'mobile', 'ess'. |
| inherit | Inherit | boolean | Whether child tables inherit this policy. Only relevant for policies on extended tables. |
| global | Global | boolean | Legacy field for domain separation. Use sys_domain instead for current domain controls. |
| reverse_if_false | Reverse if false | boolean | Undoes policy actions when conditions become false. Critical for dynamic form behavior. |
| script_true | Script true | script | JavaScript executed when conditions evaluate to true. Runs after standard policy actions. |
| script_false | Script false | script | JavaScript executed when conditions evaluate to false. Only runs if reverse_if_false is true. |
| sys_scope | Application | reference | Application scope that owns this policy. Affects visibility and modification permissions. |

Page: https://thesnowball.co/table/sys_ui_policy

## sys_update_set (Update Set)

The sys_update_set table stores update set records that container configuration changes for migration between ServiceNow instances. Part of the Development module. The critical gotcha: update sets in 'ignore' state still exist in the database and can cause unexpected query results.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | The display name of the update set. Must be unique per instance, and ServiceNow automatically appends numbers for duplicates. |
| state | State | choice | Current state: build, complete, ignore, etc. The 'ignore' state hides the update set from most UI lists but records still exist in the database. |
| application | Application | reference | References sys_app for scoped applications. Empty/null for global update sets, which affects visibility in scoped applications. |
| description | Description | string | Free text description of the update set's purpose. Not indexed, so avoid using in query conditions for performance. |
| is_default | Is Default | boolean | Marks the default update set for new changes. Multiple update sets can have this flag set across different applications. |
| release_date | Release Date | glide_date | Manually set target release date. Not automatically updated when state changes occur, so may not reflect actual deployment timing. |
| install_date | Install Date | glide_date_time | Timestamp when the update set was committed/installed. Only populated after successful commitment to target instance. |
| origin_sys_id | Origin sys_id | string | The sys_id of this update set on the originating instance. Used to track update sets across instance transfers. |
| remote_base_update_set | Remote Base Update Set | reference | References the sys_remote_update_set record when this local update set was created from a remote import. |
| base_update_set | Base Update Set | reference | Self-reference to parent update set for batched update sets. Most update sets have this field empty. |
| is_merge_update_set | Is Merge Update Set | boolean | Indicates this update set was created to resolve merge conflicts during remote update set commitment. |
| installed_from | Installed From | string | Source instance name where this update set originated. Populated during retrieval from remote instances. |

Page: https://thesnowball.co/table/sys_update_set

## sys_update_xml (Update Set Entry)

The sys_update_xml table stores individual configuration change records within update sets, with each record containing the XML representation of a modified configuration item. Owned by the Development module, this table is the foundation of ServiceNow's change tracking system. The critical thing to know: never modify the payload field directly unless you fully understand the XML schema consequences.

| Field | Label | Type | Notes |
|---|---|---|---|
| update_set | Update set | reference | References the parent sys_update_set record. This is the primary way to group and filter changes for deployment. |
| name | Name | string | Unique identifier for this specific change entry. Format typically includes table name and sys_id of the modified record. |
| action | Action | string | Indicates the type of change: INSERT, UPDATE, or DELETE. DELETE actions have empty payload fields since the record no longer exists. |
| state | State | string | Current processing state as string values: 'current' or 'previous'. Not a choice field, so queries must use exact string matches. |
| payload | Payload | string | Complete XML representation of the configuration change. Can exceed 4MB for complex items and causes performance issues in large result sets. |
| target_name | Target name | string | Name of the configuration item being changed. For table fields, includes full table.field_name format rather than just the field name. |
| type | Type | string | Category of configuration being changed (e.g., 'Business Rule', 'Table', 'Field'). Useful for grouping changes by configuration type. |
| target_table | Target table | string | Name of the table containing the configuration item. Critical for filtering changes by specific tables or modules. |
| category | Category | string | Broader classification of the change type. Often empty but can provide additional context for certain configuration types. |
| remote_update_set | Remote update set | reference | References sys_remote_update_set when this change came from another instance. Null for locally created changes. |
| update_guid | Update GUID | string | Global unique identifier for tracking this change across instances. Essential for preventing duplicate applications during deployment. |
| replaced_by | Replaced by | reference | References another sys_update_xml record when this change has been superseded. Used in conflict resolution workflows. |
| collision_detected | Collision detected | boolean | Indicates whether ServiceNow detected a conflict with existing configuration during update set processing. |
| is_merge_update | Is merge update | boolean | Marks records created during update set merge operations. These changes represent conflict resolutions rather than original modifications. |

Page: https://thesnowball.co/table/sys_update_xml

## sys_user (User)

The sys_user table contains all user accounts, profiles, and authentication data in ServiceNow. Part of the core Platform, it's referenced by virtually every other table through assignment fields, approvals, and audit columns. Key gotcha: active status doesn't mean what you think — check locked_out and web_service_access_only flags too.

| Field | Label | Type | Notes |
|---|---|---|---|
| user_name | User ID | string | Unique login identifier. Case-sensitive in queries but case-insensitive for authentication — causes confusion in script comparisons. |
| active | Active | boolean | Controls login access only. Inactive users can still be assigned to records and receive notifications — check other status fields too. |
| locked_out | Locked out | boolean | Account locked due to failed login attempts or admin action. Takes precedence over active status for access decisions. |
| web_service_access_only | Web service access only | boolean | User can authenticate via REST/SOAP but cannot access the UI. Critical for integration service accounts. |
| employee_number | Employee number | string | Often used as unique identifier in HR integrations. Indexed for performance but can be null for contractors or external users. |
| email | Email | email | Primary email address for notifications. Not unique by default — multiple users can share emails, breaking notification delivery logic. |
| department | Department | reference | References cmn_department table. Commonly used for assignment rules and reporting. Can be null for external users. |
| manager | Manager | reference | Self-referencing to sys_user. Can create circular hierarchies — always validate manager chains to prevent infinite loops in approvals. |
| location | Location | reference | References cmn_location table. Used for regional assignment rules and asset management. Often drives timezone calculations. |
| source | Source | string | Identifies user origin: 'ldap', 'okta', etc. LDAP users get overwritten on sync — check before manual updates. |
| time_zone | Time zone | string | User's timezone preference for date/time display. Critical for SLA calculations and scheduled notifications across regions. |
| roles | Roles | user_roles | Comma-separated role list field. Read-only display — actual role assignments stored in sys_user_has_role table. |
| groups | Groups | glide_list | Shows group memberships from sys_user_grmember table. Updates here don't persist — manage via group membership records directly. |
| last_login_time | Last login | glide_date_time | System-updated timestamp of last successful login. Useful for identifying inactive accounts in cleanup scripts. |
| failed_attempts | Failed attempts | integer | Count of consecutive failed login attempts. Auto-resets on successful login. Used for account lockout policies. |
| ldap_server | LDAP server | reference | References ldap_server_config for LDAP-sourced users. Determines sync behavior and password policies. |
| vip | VIP | boolean | Marks high-priority users for special handling in incidents and requests. Often drives SLA and assignment rules. |
| cost_center | Cost center | reference | References cmn_cost_center for financial tracking. Used in approval workflows and cost allocation for services and assets. |

Page: https://thesnowball.co/table/sys_user

## sys_user_grmember (Group Member)

The sys_user_grmember table stores the many-to-many relationship between users and groups in ServiceNow. It's owned by the Platform module and serves as the junction table for all group membership across the platform. Always filter by the active field when checking current memberships to avoid performance issues and stale data.

| Field | Label | Type | Notes |
|---|---|---|---|
| user | User | reference | Reference to sys_user table. Stores sys_id as string - use .toString() when comparing to avoid type coercion issues in scripts. |
| group | Group | reference | Reference to sys_user_group table. Combined with user field creates the many-to-many relationship. Always indexed for performance. |
| state | State | choice | Active/Inactive status of the membership. Critical field - inactive records persist for audit but queries must filter for 'active' to get current memberships. |
| sys_created_on | Created | glide_date_time | When the group membership was established. Useful for audit trails and determining membership duration for compliance reporting. |

Page: https://thesnowball.co/table/sys_user_grmember

## sys_user_group (Group)

The sys_user_group table stores all groups in ServiceNow, including assignment groups for tasks, approval groups for workflows, and security groups for access control. Owned by the Platform module, it's the foundation of ServiceNow's role-based assignment and approval processes. Groups can be hierarchical with manager relationships, and a single user can belong to multiple groups through the sys_user_grmember table.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Unique group identifier displayed in assignment and approval UIs. Case-insensitive uniqueness constraint—'Service Desk' conflicts with 'SERVICE DESK'. |
| type | Type | string | Categorizes groups for filtering in reference qualifiers. No referential integrity—invalid values break UI filters but don't error. |
| active | Active | boolean | Controls visibility in reference field selections. Inactive groups remain on existing assignments but can't be selected for new ones. |
| email | Email | string | Group email address used for notifications when individual member emails aren't specified. Empty value breaks group notifications. |
| manager | Manager | reference | References another group record for hierarchical relationships and escalation paths. Circular references cause infinite loops in traversal scripts. |
| description | Description | string | Free-text field describing the group's purpose and responsibilities. Commonly used in approval workflows to display group context. |
| source | Source | string | Identifies how the group was created—manual, LDAP import, or automated process. Critical for data governance and sync processes. |
| cost_center | Cost center | reference | References cmn_cost_center for financial reporting and charge-back processes. Used in time tracking and expense allocation. |
| include_members | Include members | boolean | Controls whether group notifications include individual members or just the group email. Affects notification volume and delivery. |
| default_assignee | Default assignee | reference | References sys_user for automatic individual assignment when tasks come to this group. Bypasses group assignment logic. |
| parent | Parent | reference | Creates organizational hierarchy separate from manager relationship. Used for reporting rollups and inherited permissions. |
| roles | Roles | string | Comma-separated list of roles inherited by group members. Automatically grants access without individual role assignments. |
| u_custom_field | Custom Fields | varies | Organizations commonly add location, business unit, or escalation path fields. Check your instance's customizations before scripting. |

Page: https://thesnowball.co/table/sys_user_group

## sys_user_has_role (User Role)

The `sys_user_has_role` table stores direct role assignments to individual users, separate from group-inherited roles. Owned by the Platform module, the critical thing to know is that this only shows explicit assignments — not inherited roles from groups.

| Field | Label | Type | Notes |
|---|---|---|---|
| user | User | reference | References sys_user. The user receiving the direct role assignment. Cannot be empty and must reference an active user record. |
| role | Role | reference | References sys_user_role. The role being directly assigned to the user. System roles like 'admin' appear here alongside custom roles. |
| state | State | choice | Active or inactive status of the role assignment. Defaults to 'active' but can be set to 'inactive' to temporarily disable without deletion. |
| granted_by | Granted by | reference | References sys_user for who created this assignment. Often empty for system-generated assignments, making audit trails incomplete. |
| inh_count | Inheritance count | integer | Computed field showing inheritance depth. Can become stale and shouldn't be relied upon for real-time permission calculations. |
| included_in_role | Included in role | reference | References sys_user_role when this assignment exists due to role inheritance. Empty for true direct assignments. |
| included_in_role_instance | Included in role instance | reference | References the specific sys_user_has_role record that caused this inheritance. Used internally by the role inheritance engine. |

Page: https://thesnowball.co/table/sys_user_has_role

## sys_user_role (Role)

The sys_user_role table defines security roles that control access to features and records throughout ServiceNow. Owned by the Platform module, it's the foundation of ServiceNow's role-based access control system. The critical thing to know: roles are hierarchical and cumulative — having multiple roles grants the union of their permissions, not the intersection.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | The unique role identifier used in gs.hasRole() calls and ACL conditions. Changing this value breaks existing security rules referencing the old name. |
| description | Description | string | Human-readable role description, often empty or generic. Don't rely on this for programmatic logic — use the name field instead. |
| active | Active | boolean | Controls role availability for assignment. Inactive roles remain effective for existing users until session refresh or role cache invalidation. |
| elevated_privilege | Elevated privilege | boolean | Marks high-security roles that may require additional authentication. Used by security plugins and elevated privilege workflows. |
| assignable_by | Assignable by | reference | References another role that can grant/revoke this role. Empty means only admins can assign. Creates delegation hierarchies for role management. |
| contains_roles | Contains roles | string | Comma-separated list of role names that this role inherits. Enables role hierarchy where higher-level roles automatically include lower-level permissions. |
| can_delegate | Can delegate | boolean | Allows users with this role to delegate it to others if they also have appropriate assignment permissions. Used in approval and workflow scenarios. |
| suffix | Suffix | string | Appended to role name in UI displays and lists. Affects sorting behavior — blank suffix roles appear before suffixed ones regardless of alphabetical order. |
| requires_subscription | Requires subscription | string | Plugin or subscription requirement for role availability. Empty for base platform roles, populated for licensed application roles like ITOM or CSM. |
| grantable | Grantable | boolean | Controls whether this role can be assigned through standard role assignment mechanisms. False prevents normal assignment while allowing programmatic grants. |
| includes_roles | Includes roles | string | Calculated field showing roles that include this role in their contains_roles list. Read-only field used for hierarchy visualization and dependency tracking. |

Page: https://thesnowball.co/table/sys_user_role

## sys_ws_definition (Scripted REST Service)

The sys_ws_definition table stores Scripted REST API service definitions in the Integration module. Each record represents a REST service container that holds multiple resources and their HTTP methods.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Display name for the REST service. Must be unique within the application scope and becomes part of the service's identity in API documentation. |
| namespace | API Namespace | string | URL namespace that groups related services. Forms part of the endpoint URL structure and should follow RESTful naming conventions. |
| base_path | Base API Path | string | The root path for all operations in this service. Must be unique across active services and starts with a forward slash. |
| active | Active | boolean | Controls whether the service endpoints are accessible. Inactive services return 404 errors but remain visible in the platform UI. |
| authentication_type | Authentication Type | choice | Default authentication method for operations in this service. Individual operations can override this setting, making service-level queries incomplete. |
| short_description | Short Description | string | Brief description of the service's purpose. Appears in API documentation and service catalogs, so keep it business-friendly. |
| version | Version | string | Free-text version identifier with no enforcement. Multiple services can claim the same version number with different implementations. |
| doc_link | Documentation Link | string | Relative path to service documentation. The platform doesn't validate that documentation exists at this location. |
| enforce_acl | Enforce ACL | boolean | Whether to apply Access Control List rules to service operations. Critical for security but can impact performance on high-volume APIs. |
| consumes | Consumes | string | Comma-separated list of MIME types this service can consume. Defaults to application/json but operations can override this. |
| produces | Produces | string | Comma-separated list of MIME types this service can produce. Individual operations inherit this but can specify their own response types. |
| sys_scope | Application | reference | References the application scope that owns this service. Critical for determining visibility and deployment boundaries across instances. |
| web_service_definition | Web Service Definition | reference | Optional reference to related WSDL-based web service definitions. Rarely used in modern REST implementations but maintained for compatibility. |
| service_id | Service ID | string | Internal identifier used by the REST framework. Auto-generated and should not be modified manually as it affects endpoint routing. |
| relative_path | Relative Path | string | Computed field combining namespace and base_path. Read-only and used internally for URL routing and endpoint resolution. |

Page: https://thesnowball.co/table/sys_ws_definition

## sysapproval_approver (Approval)

The sysapproval_approver table stores individual approval records that require user action, owned by the Platform module. Before querying, understand that each approval record represents one person's approval decision in a larger approval chain.

| Field | Label | Type | Notes |
|---|---|---|---|
| approver | Approver | reference | References sys_user table for the person assigned to make the approval decision. Can reference inactive users, so always check approver.active in queries. |
| state | State | choice | Approval lifecycle state using unique values: 'requested' (active), 'approved', 'rejected', 'cancelled', 'not required'. Not the standard task state values. |
| document_id | Document ID | string | sys_id of the source record requiring approval (Change Request, Catalog Request, etc). Combined with source_table to identify the parent record. |
| source_table | Source Table | string | Table name (not reference) of the record requiring approval. Stores values like 'change_request' or 'sc_req_item' as strings. |
| sysapproval | Parent Approval | reference | References the parent sysapproval record that groups related approver records together. Multiple approvers share the same parent approval. |
| approval | Approval | choice | The actual approval decision: 'approved', 'rejected', or empty for pending. Often mirrors state but can differ during processing. |
| due_date | Due Date | glide_date_time | When approval expires or requires escalation. Can be empty even with SLA configuration—check task SLA records for complete escalation logic. |
| comments | Comments | string | Approver's explanation for their decision. Often required by approval policies for rejected approvals but can be optional for approved ones. |
| expected_start | Expected Start | glide_date_time | When approval process should begin. Used by approval workflows to delay approval requests until specific dates or conditions. |
| group | Group | reference | References sys_user_group when approval is assigned to a group rather than individual user. Group approvals allow any group member to respond. |
| wf_activity | Workflow Activity | reference | Links to workflow activity that generated this approval. Used when approvals are part of structured workflow processes rather than simple approval rules. |
| approving_type | Approving Type | choice | Indicates approval mechanism: 'user', 'group', or 'anyone'. Affects which users can respond to the approval request and how responses are processed. |
| delegate | Delegate | reference | sys_user reference when approval is delegated to another user. Original approver remains in approver field, actual decision maker stored here. |
| escalation_rule | Escalation Rule | reference | References sysrule_escalate record defining escalation behavior. Links approval to specific escalation policies for overdue responses. |
| tree_path | Tree Path | string | Hierarchical path showing approval chain sequence. Format like '0001.0002' indicates approval order and dependencies within complex approval trees. |

Page: https://thesnowball.co/table/sysapproval_approver

## sysauto_script (Scheduled Script Execution)

The sysauto_script table manages scheduled scripts that run on cron schedules, owned by the Platform module. Before querying it, know that this table doesn't run the scripts — it just stores the configuration and execution metadata.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Unique identifier for the scheduled job. Must be unique across the system and is used by APIs to reference specific jobs. |
| active | Active | boolean | Controls whether the job executes on schedule. Changes take effect before the next scheduled run, not immediately for currently running jobs. |
| script | Script | script_plain | JavaScript code to execute. Runs in global scope regardless of application scope, with full system privileges unless run_as is specified. |
| run_time | Run time | string | Cron expression defining when the job runs. Modifying this field requires updating the associated sys_trigger record to take effect. |
| run_as | Run as | reference | Reference to sys_user for execution context. Empty values run with full system privileges, not as the job creator. |
| last_run | Last run | glide_date_time | Timestamp of most recent execution attempt. Updates even if the script fails or throws an exception. |
| run_start | Run start | glide_date_time | When the current or last execution began. Used to detect long-running or stuck jobs. |
| run_type | Run type | choice | Execution mode: 'on_demand' for manual runs, 'periodically' for scheduled execution, or 'once' for single execution. |
| conditional | Condition | conditions | Optional condition that must evaluate true before script execution. Checked each time before the job runs. |
| description | Description | string | Human-readable description of the job's purpose. Critical for maintenance since job names are often cryptic technical identifiers. |
| job_context | Job context | string | Additional context passed to the executing script. Accessible within the script but rarely used in practice. |
| run_dayofweek | Run day of week | integer | Day of week for weekly schedules (0=Sunday). Only relevant when run_time uses weekly cron patterns. |
| run_dayofmonth | Run day of month | integer | Day of month for monthly schedules. Only relevant when run_time uses monthly cron patterns. |
| upgrade_safe | Upgrade safe | boolean | Whether the job should run during platform upgrades. Set to false for jobs that might conflict with upgrade processes. |
| time_zone | Time zone | string | Time zone for schedule interpretation. Defaults to system time zone if not specified, which can cause confusion across regions. |

Page: https://thesnowball.co/table/sysauto_script

## sysevent (System Event)

The `sysevent` table stores asynchronous events created by `gs.eventQueue()` and consumed by notifications, script actions, and flow triggers. Part of Platform's event processing engine. Key gotcha: events are consumed and deleted automatically, so you'll often query an empty table in dev instances.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Event Name | string | The event name that triggered this record, like 'record.insert' or 'custom.approval'. Script actions and flows subscribe to specific event names. |
| state | State | choice | Processing state: 0=Ready, 1=Processing, 2=Processed, 3=Error. Events stuck in Processing state indicate failed processors that need manual cleanup. |
| table | Table | string | The table name of the record that triggered this event. Used with the instance field to identify the specific record. |
| instance | Instance | string | The sys_id of the record that triggered this event. Combined with table field, gives you the exact record reference. |
| parm1 | Parameter 1 | string | Serialized object containing event parameters. Don't parse manually—use gs.eventQueue() API which handles serialization properly. |
| parm2 | Parameter 2 | string | Additional serialized parameters for the event. Often contains record snapshots or custom data passed to gs.eventQueue(). |
| claimed_by | Claimed By | string | Background process ID that claimed this event for processing. Empty means available for processing, non-empty means being processed. |
| process_on | Process On | glide_date_time | Earliest time this event should be processed. Allows for delayed event processing and scheduled background tasks. |
| processed | Processed | glide_date_time | Timestamp when event processing completed. Only set for processed or error state events before they get purged. |
| queue | Queue | string | Processing queue name for prioritization. Default is 'default' but custom queues can be created for different processing priorities. |
| source | Source | string | Application scope or source that created this event. Helps track which application or process is generating events. |
| user_id | User ID | reference | Reference to sys_user who triggered the event. Maintains user context for security and auditing in background processing. |
| uri | URI | string | URL or resource identifier related to the event. Often contains REST API endpoints or form URLs for context. |
| error_string | Error String | string | Error message when event processing fails. Only populated for events in error state before they get purged. |
| extra_info | Extra Info | string | Additional context information for the event. Format varies by event type—could be JSON, key-value pairs, or plain text. |

Page: https://thesnowball.co/table/sysevent

## syslog (System Log Entry)

The syslog table stores all server-side log messages generated by gs.log(), gs.info(), gs.warn(), and gs.error() calls. Part of the Platform module. Always query with date ranges and specific filters — this table grows massive at enterprise scale.

| Field | Label | Type | Notes |
|---|---|---|---|
| created_on | Created | glide_date_time | When the log entry was generated. Always query with date filters — this table grows massive and unfiltered queries will timeout. |
| level | Level | integer | Log severity as integer: 0=error, 1=warn, 2=info, 3=debug. UI shows string labels but queries must use numeric values. |
| message | Message | string | The actual log message content. Truncated at 4000 characters — longer messages are silently cut off. |
| source | Source | string | Where the log entry originated — Business Rule name, Script Include, or system process. Scoped app entries include scope prefix. |
| user_name | User name | string | Username who triggered the logged action. Often empty for system processes, scheduled jobs, and background operations. |
| session_id | Session ID | string | Browser session that generated the log entry. Useful for tracking user activity patterns but empty for server-side background processes. |
| transaction_id | Transaction ID | string | Groups related log entries from the same request/response cycle. Critical for debugging complex workflows with multiple script executions. |
| sequence | Sequence | integer | Order of log entries within the same transaction. Higher numbers indicate later execution in the processing chain. |
| method | Method | string | HTTP method (GET, POST, PUT) for request-triggered log entries. Empty for background processes and scheduled operations. |
| url | URL | string | Request URL that triggered the log entry. Helps identify which forms or list views generated specific errors. |
| user_agent | User agent | string | Browser user agent string from the request. Useful for identifying mobile vs desktop issues or browser-specific problems. |
| thread | Thread | string | Server thread identifier that processed the request. Advanced debugging field for performance analysis and thread contention issues. |
| type | Type | string | Log entry category — typically 'system' for platform operations or empty for developer-generated gs.log() calls. |
| class_name | Class name | string | Java class name for system-generated entries. Usually empty for JavaScript-based Business Rule or Script Include logging. |
| method_name | Method name | string | Specific method within the class that generated the log entry. Primarily used for Java-based system logging, not custom scripts. |

Page: https://thesnowball.co/table/syslog

## task (Task)

The task table is the foundation of ServiceNow's work management, storing common fields for incidents, problems, changes, requests, and more. Owned by the Platform module, it's rarely queried directly but provides the base schema for most ITSM workflows.

| Field | Label | Type | Notes |
|---|---|---|---|
| number | Number | string | Auto-generated identifier using different prefixes per child table (INC, PRB, CHG, REQ). Read-only after creation and unique within each child table type, not across all tasks. |
| state | State | choice | Current workflow state using different choice lists per child table. Incident state 6 is 'Resolved' while Change Request state 3 is 'Authorize' - always check sys_class_name when interpreting. |
| assigned_to | Assigned to | reference | References sys_user for individual assignment. Changes trigger assignment Business Rules and email notifications. Can be null when work is only group-assigned. |
| assignment_group | Assignment group | reference | References sys_user_group for group assignment. Index exists for performance but bulk assignment group changes can still cause timeouts due to cascading Business Rules. |
| caller_id | Caller | reference | References sys_user who reported or initiated the work. Drives ACL visibility in many implementations and affects notification recipients. |
| opened_by | Opened by | reference | References sys_user who created the record. Auto-populated on insert and rarely changed manually. Used for audit trails and creator-based reporting. |
| opened_at | Opened | glide_date_time | Timestamp when record was created. Auto-populated and used for SLA calculations and aging reports. Timezone-sensitive in global instances. |
| closed_at | Closed | glide_date_time | Timestamp when record reached a closed state. Automatically populated by platform workflows but can be manually overridden. Null for open records. |
| close_code | Close code | choice | Reason for closure with different choice lists per child table. Often required by business rules before allowing state transitions to closed states. |
| close_notes | Close notes | string | Free text explanation of resolution or closure reason. Commonly required by UI policies when close_code is populated. |
| short_description | Short description | string | Brief summary line shown in lists and notifications. 160 character limit enforced by platform. Often used in search and matching algorithms. |
| description | Description | html | Full HTML-enabled problem description. Accepts rich text formatting and can contain embedded images. Search behavior differs from plain text fields. |
| work_notes | Work notes | journal_input | Internal-only journal entries for team communication. Not visible to end users by default ACLs. Creates journal entries in task_activity table. |
| comments | Comments | journal_input | Public journal entries visible to requestors. Creates entries in task_activity table with different visibility flags than work_notes. |
| priority | Priority | choice | Business priority rating typically calculated from impact and urgency. Used for queue sorting and SLA selection. Choice values consistent across most child tables. |
| impact | Impact | choice | Scope of business effect rated 1-3 (High-Low). Combined with urgency to calculate priority via Business Rules in many implementations. |
| urgency | Urgency | choice | Time sensitivity rated 1-3 (High-Low). Combined with impact to calculate priority. Can be auto-populated based on caller VIP status. |
| cmdb_ci | Configuration Item | reference | References cmdb_ci table for affected infrastructure. Enables impact analysis and change coordination. Table name matches field name confusingly. |
| active | Active | boolean | Indicates if record is in an active workflow state. Behaves as string 'true'/'false' in some contexts, not boolean true/false in GlideRecord queries. |
| approval | Approval | choice | Aggregated approval state from approval_approver records. Values include 'approved', 'rejected', 'requested'. Auto-updated by approval workflow engine. |

Page: https://thesnowball.co/table/task

## task_sla (Task SLA)

The task_sla table stores SLA tracking records automatically created by ServiceNow's SLA engine for individual task records. Owned by the ITSM module, this table tracks breach percentages, pause states, and duration calculations. The critical thing to know: these records are managed by the SLA engine — direct manipulation can break SLA calculations.

| Field | Label | Type | Notes |
|---|---|---|---|
| task | Task | reference | References the task record this SLA applies to. This is your primary join field — always indexed and required for efficient queries. |
| sla | SLA Definition | reference | References the contract_sla record that defines this SLA's rules. Use this to access SLA name, duration, and threshold settings. |
| stage | Stage | string | Current SLA stage: 'in_progress', 'paused', 'completed', 'cancelled'. String values only — no integer comparisons. Critical for filtering active SLAs. |
| percentage | Percentage | decimal | Percentage of SLA time consumed. Values >100 indicate breached SLAs. Calculated by SLA engine — don't modify directly. |
| active | Active | boolean | Indicates if this SLA instance is currently active. Multiple SLA records can exist per task — filter by active=true for current status. |
| planned_end_time | Planned End Time | glide_date_time | When this SLA is scheduled to breach. Calculated based on schedule and pause conditions. Use for due date displays and escalation triggers. |
| start_time | Start Time | glide_date_time | When SLA tracking began for this record. Usually matches task creation time but can differ based on SLA start conditions. |
| end_time | End Time | glide_date_time | When SLA tracking ended (completion or cancellation). Empty for active SLAs. Use to calculate actual duration for reporting. |
| business_pause | Business Pause | boolean | Manual pause flag that stops SLA calculations. Changes only affect future calculations — doesn't retroactively adjust duration. |
| pause_time | Pause Time | glide_date_time | Total time this SLA has been paused (in seconds). Includes both business_pause and automatic pause conditions. Read-only field. |
| duration | Duration | glide_duration | Actual elapsed time for this SLA in business hours. Excludes pause time. Calculated by SLA engine using schedule definitions. |
| business_duration | Business Duration | glide_duration | Elapsed business time excluding weekends and holidays. Based on the schedule associated with the SLA definition. |
| schedule | Schedule | reference | References cmn_schedule record used for business hours calculations. Inherited from SLA definition but can be overridden per instance. |
| timezone | Time Zone | string | Time zone for SLA calculations. Usually inherited from schedule or user preferences. Affects planned_end_time calculations. |
| has_breached | Has Breached | boolean | True if this SLA has exceeded its time limit (percentage >= 100). Remains true even after task completion for reporting purposes. |
| breach_time | Breach Time | glide_date_time | Timestamp when this SLA first breached. Empty for non-breached SLAs. Critical for breach duration reporting and escalation tracking. |

Page: https://thesnowball.co/table/task_sla

## ua_task (HR Case)

The ua_task table stores HR Service Delivery (HRSD) case records and extends the task table with HR-specific fields. Owned by the HRSD module, it's the primary table for employee HR requests, issues, and services. The key thing to know: it inherits all task behaviors but adds HR-specific workflows and field validations that can affect your scripts.

| Field | Label | Type | Notes |
|---|---|---|---|
| number | Number | string | Auto-generated unique case identifier with HR prefix (e.g., HRC0001234). Uses a separate number series from other task types. |
| employee | Employee | reference | References sys_user - the employee the case is about (not necessarily who opened it). Can differ from opened_by when HR agents create cases. |
| hr_profile | HR Profile | reference | References hr_profile table for comprehensive employee data. Can be null for terminated employees, breaking reference field queries. |
| hr_service | HR Service | reference | References hr_service_catalog. Has complex reference qualifiers based on employee location/department that can cause direct assignment failures. |
| state | State | integer | Uses custom HR-specific state values like 'Pending Employee' and 'Pending Approval' that don't map to standard task states. |
| priority | Priority | integer | Inherits from task but HR cases use different priority calculation logic based on service type and employee level. |
| urgency | Urgency | integer | Drives SLA calculations specific to HR service levels. Auto-calculated based on employee VIP status and request type. |
| impact | Impact | integer | Determined by employee role and department for HR-specific impact assessment, not standard IT impact rules. |
| assigned_to | Assigned to | reference | References sys_user for the assigned HR agent. Auto-assignment rules consider HR service type and employee location. |
| assignment_group | Assignment group | reference | References sys_user_group for HR teams. Often location-specific groups like 'HR - New York' or service-specific like 'HR - Benefits'. |
| opened_by | Opened by | reference | References sys_user - who created the case. Can be the employee themselves or an HR agent acting on their behalf. |
| short_description | Short description | string | Brief case summary. Often auto-populated based on hr_service selection through catalog item templates. |
| description | Description | string | Detailed case description. May contain sensitive employee information subject to field-level encryption in some implementations. |
| work_notes | Work notes | journal_input | Internal HR agent notes not visible to employees. Critical for case documentation and handoffs between HR teams. |
| comments | Additional comments | journal_input | Customer-visible communication log. Employees can see these comments when checking case status through ESS portal. |
| due_date | Due date | glide_date_time | Target resolution date calculated from HR SLA definitions. Critical for HR service level compliance reporting. |
| resolved_at | Resolved | glide_date_time | Timestamp when case reached resolved state. Used for HR SLA compliance calculations and resolution time metrics. |
| closed_at | Closed | glide_date_time | Final case closure timestamp. HR cases often have a waiting period between resolved and closed for employee confirmation. |
| business_service | Business service | reference | References cmdb_ci_service for HR service mapping. Used for service catalog integration and HR service portfolio management. |
| contact_type | Contact type | string | How the employee contacted HR (phone, email, walk-in, portal). Important for channel analytics and resource planning. |

Page: https://thesnowball.co/table/ua_task

## wf_context (Workflow Context)

The wf_context table tracks active workflow execution instances in ServiceNow's Workflow module. Each record represents a running workflow with its current state, activity position, and execution context. The critical thing to know: workflows only create context records when they actually execute—draft workflows won't appear here.

| Field | Label | Type | Notes |
|---|---|---|---|
| workflow | Workflow | reference | References wf_workflow table containing the workflow definition. This tells you which workflow is executing, but you'll need to dot-walk to get the workflow name. |
| state | State | integer | Workflow execution state as integer: 1=Executing, 2=Waiting, 3=Finished, 4=Cancelled, 7=Error. Most debugging queries filter for != 3 to find active workflows. |
| document_id | Document ID | string | The sys_id of the record this workflow is operating on. It's a string field, not a reference, so you can't dot-walk but must do separate queries to get record details. |
| table | Table | string | The table name (like 'incident' or 'change_request') that contains the record being processed. Essential for performance when querying by document_id. |
| current_activity | Current Activity | reference | References wf_activity table showing which workflow activity is currently executing. Null when workflow is starting up or finishing. |
| started | Started | glide_date_time | When this workflow execution began. Uses system timezone, not user timezone—important for time-based analysis and SLA calculations. |
| ended | Ended | glide_date_time | When workflow execution completed (finished, cancelled, or errored). Null for active workflows—use this to calculate execution duration. |
| scratchpad | Scratchpad | string | XML-serialized workflow variables and context data. Don't parse as JSON—use Workflow API methods or XML parsing to extract variable values. |
| fault_description | Fault Description | string | Error message when workflow execution fails. Only populated when state=7 (Error). Contains the actual JavaScript error or timeout message. |
| business_key | Business Key | string | Optional identifier for grouping related workflow executions. Workflows can set this to track multi-step processes or batch operations. |
| phase | Phase | integer | Internal workflow engine state tracking execution phase. Used by the engine for flow control—not typically useful for custom scripting. |
| stage | Stage | string | Current execution stage within the workflow engine. Values like 'begin', 'activity', 'end' track where the engine is in processing this context. |
| activity_index | Activity Index | integer | Position counter for the current activity in the workflow sequence. Useful for understanding how far through the workflow execution has progressed. |
| workflow_version | Workflow Version | reference | References wf_workflow_version for the specific workflow version being executed. Important when workflows are updated but existing contexts continue on old versions. |
| started_by | Started By | reference | References sys_user who initiated the workflow execution. May be system user for automated triggers or the actual user for manual workflow starts. |

Page: https://thesnowball.co/table/wf_context

## wf_workflow (Workflow)

The wf_workflow table stores legacy Workflow definitions from the Workflow module, used before Flow Designer was introduced. These workflows are still heavily used on older instances, and developers need to understand their state management and execution context when scripting against them.

| Field | Label | Type | Notes |
|---|---|---|---|
| name | Name | string | Human-readable workflow name. Must be unique per table but can be duplicated across different tables. |
| table | Table | string | Target table name where this workflow operates. Stored as string table name, not a reference to sys_db_object. |
| active | Active | boolean | Controls whether workflow can be triggered. Inactive workflows won't start new executions but running instances continue. |
| published | Published | string | String value 'true' or 'false' indicating if workflow is published. Unpublished workflows won't execute even if active=true. |
| condition | Condition | string | Encoded query string defining when workflow triggers. Uses same format as GlideRecord.addEncodedQuery(), not JavaScript. |
| on_insert | Run on Insert | boolean | Triggers workflow when new records are created on the target table. Combines with condition field for filtering. |
| on_update | Run on Update | boolean | Triggers workflow when records are updated on the target table. Most common trigger type for approval workflows. |
| on_delete | Run on Delete | boolean | Triggers workflow when records are deleted from the target table. Rarely used due to cleanup timing issues. |
| description | Description | string | Free-text description of workflow purpose. Important for documentation since workflows can be complex. |
| version | Version | string | Manual version identifier. Unlike Flow Designer, this doesn't auto-increment and must be managed manually. |
| begin | Begin Activity | reference | References wf_activity record that serves as workflow entry point. Required for workflow execution to start. |
| stage | Stage | choice | Workflow lifecycle stage: 'development', 'test', 'production'. Affects visibility in workflow designer. |
| expected_time | Expected Duration | integer | Expected runtime in seconds. Used for SLA calculations and workflow performance monitoring. |
| relative_duration | Relative Duration | string | Duration specification using relative time format. Can reference field values from the triggering record. |
| checked_out | Checked Out | boolean | Indicates if workflow is currently being edited in workflow designer. Prevents concurrent modifications. |
| checked_out_by | Checked Out By | reference | References sys_user who has workflow checked out for editing. Automatically cleared when designer is closed. |
| run_as | Run As | reference | References sys_user whose permissions workflow activities inherit. Defaults to system user if not specified. |

Page: https://thesnowball.co/table/wf_workflow