cmdb_ci_appl

What This Table Is

The cmdb_ci_appl table stores Application Configuration Items representing software products, applications, and business systems in your organization. These CIs capture both technical applications (like databases, web servers, custom applications) and business applications (like ERP systems, CRM platforms, or internally developed solutions).

Owned by the CMDB module, this table sits at the heart of IT asset management and service mapping. Application CIs typically form the middle layer of your service topology—sitting above infrastructure CIs (servers, databases) and below business service CIs. They're essential for impact analysis, change management, and understanding your application portfolio.

This table extends cmdb_ci, inheriting core CI fields like operational_status, support_group, and relationship management capabilities. No tables typically extend cmdb_ci_appl directly—instead, organizations use CI class inheritance or create custom CI classes for specialized application types.

In large enterprises, expect 1,000-5,000 application CIs with complex relationship webs. Queries involving relationships or deep hierarchy traversal can be expensive. The table performs well for direct lookups and filtering by status or business criticality, but relationship queries benefit from indexed approaches and strategic caching.

When You'll Script Against This Table

You'll primarily script against cmdb_ci_appl in Business Rules during change management workflows, Script Includes for service mapping automation, and Scheduled Jobs for application portfolio reporting. Discovery and Service Mapping processes heavily interact with this table through automated relationship building and CI lifecycle management.

Access typically requires cmdb_read or cmdb_write roles, with additional business service ACLs potentially restricting access to critical application CIs. Domain separation commonly applies, filtering records by application owner or business unit.

Common scripting patterns:

• Finding downstream impacts during change approval workflows
• Auto-populating application context in incidents and requests
• Building service dependency maps for business continuity planning
• Calculating application portfolio metrics and health scores
• Synchronizing application data with external asset management systems
• Validating configuration compliance against enterprise architecture standards
• Automating ownership assignment based on application tier or business function

Table Gotchas

• The used_for field is a choice list but organizations often customize the options, making cross-environment scripts brittle
• Relationship queries using cmdb_rel_ci can be extremely expensive—ServiceNow doesn't index relationship traversal well for large datasets

• Application CIs often have circular dependencies in their relationship maps—always implement recursion protection in relationship traversal scripts
• Discovery and Service Mapping can create duplicate application CIs if name matching rules aren't configured properly—always check for existing CIs before automated creation

Related Tables

As an extension of cmdb_ci, application CIs inherit all base CI functionality and participate in the broader CMDB ecosystem. The cmdb_rel_ci table manages all relationships between application CIs and other components—from 'Runs on' relationships with servers to 'Connects to' relationships with databases.

You'll frequently join with cmdb_ci_business_app for business service mapping, sys_user_group for support team assignments, and various infrastructure CI tables like cmdb_ci_server or cmdb_ci_database for dependency analysis.

Common cross-table scenarios include correlating applications with incidents (incident), tracking changes against applications (change_request), and managing software entitlements (alm_license). Application portfolio dashboards typically require data from all these tables to provide comprehensive application health and lifecycle visibility.