Create a data model in App Engine Studio (AES) for your application by creating the tables that will house your application data. Create data tables that will be used in your application by creating the table from scratch, uploading a spreadsheet or PDF, or by using an existing table as a template. You can also create and schedule data imports by mapping a spreadsheet to an existing table in your application.

Creating a data model and populating data into user interfaces are crucial starting points for any new application. Users may provide data, such as their name and phone number, when they fill in a form, and other users may refer to data as they fulfill a request.

In App Engine Studio, application data is stored in table format. When users update application data, they create a row or change an existing row in the table (each row is also known as a data record). You can create tables from existing ServiceNow AI Platform tables, from a spreadsheet or PDF, or customize a completely new table for your application to store records in.

The data records stored in your application may come from several sources. One table might store data records entered by users who are using your application, another might be populated via the import and mapping of data from a spreadsheet or through a script that updates data records with data from another ServiceNow AI Platform table.

Application templates and data

Application templates automatically add data to your application. If you use a template to create your application, you can edit the tables that were added or add different tables.

Forms

When you add data to your app, any associated form views display in the Experience section of your app. To edit the form, select it in the Experience section. Form views can be edited in the Forms tab of Table Builder. For more information, see Forms in Table Builder.

Table extension

There are several tables that your organization may already be using in other applications. For example, your organization may be using the Configuration item [cmdb_ci] table for an application that houses configuration data. You can create a table for your application by extending any of these existing tables.

Table extension allows a table to share fields and records with a parent table. You might extend a table if you expect users to fill in similar fields across different form views in an application. For example, to create a ticketing type of table, you might extend the Task [task] table. The Task table includes fields that are standard for most work tickets, such as Number and Assigned to.

Many organizations create extensible standardized tables for their citizen developers to use when designing their apps. This enables the developers to standardize the way data is utilized across multiple applications within the organization.

To make a table in your application extensible, select Make extensible during table creation. After extending an existing table, you can further customize the new table by adding more columns.

The following table provides a list of commonly extended tables in the ServiceNow AI Platform. For more information on commonly extended tables and models for extension, see Table extension and classes.

Table 1. Commonly extended tables
TableShort DescriptionDescription
task Task Stores fields for the core applications such as Incident, Problem, and Change Management. It provides a series of standard fields used on each of the tables that extend it. Any table which extends the task table can take advantage of task-specific functionality for driving tasks.
cmdb_ci Configuration Item Stores configuration items. This table can be extended for configuration items such as hardware, services, etc.

sn_customerservice

_case

 Customer Service Case Stores customer service case records.
sm_order Service Order Stores data that defines and manages work that needs to be performed.
sm_task Service Task Stores units of work performed by one person in one session (one location, one time).
planned_task Planned Task Stores additional fields for tasks pertaining to time and effort as part of a planned, multi-stage process.
cmn_location Location Stores location information.

cmdb_serviceorder

_product_model

 Service Order Model Stores service order templates.

cmdb_servicetask

_product_mode

 Service Task Model Stores service task templates.

cmdb_qb_result

_base

 Query Results Stores query results created by the CMDB Query Builder.
alm_asset Asset Stores general, financial, and contractual information about assets.
cmdb_ci_service Business Service Stores IT Services data that directly supports a business process.
sys_user User Stores user data. The User table provides a list of all system users and their related department.
sys_user_group User Group Stores and groups a set of users who share a common purpose. Groups may perform tasks such as approving change requests, resolving incidents, receiving email notifications, or performing work order tasks.
core_company Company Stores company information.
cmn_schedule Schedule Stores records that specify a time zone and a type of schedule and use one or more schedule entries.
cmn_department Department Stores a list of all departments and their related business unit.
cmn_cost_center Cost Center Stores cost center records. This is a reference between financial systems and IT. Cost center records represent business entities, and have a related list of CI Cost Center Relationships that measure the cost center's consumption of business services.
cmdb_model Product Model Specific versions or various configurations of an asset. Models are used for managing and tracking assets through various ServiceNow platform asset applications, including Product Catalog, Asset Management, and Procurement.
life_cycle_stage Life Cycle Stage Stores standard fields and values for tracking life cycle stages for CIs. Using these standard values consistently across applications helps to effectively track assets through their life cycle transitions.

life_cycle_stage

_status

 Life Cycle Status Stores standard fields and values for tracking life cycle stage status for CIs. Using these standard values consistently across applications helps to effectively track assets through their life cycle transitions.
incident Incident Stores deviations from an expected standard of operation.
sysapproval Approval Stores data that allows you to require authorization on tasks before the work is done. You can define approvals for all tasks and associate users or groups to a task to approve or reject them.

Use the methods listed below to create a data model and add data to your application.