--- sourceDocument: Brazil ServiceNow AI Platform Administration sourceDocumentLink: https://www.servicenow.com/docs/r/platform-administration Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil ServiceNow AI Platform Administration ft:clusterId : - platadm bundleId : - platadm workflow : - Platform --- # Storage aliases # Storage aliases {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Storage aliases Storage aliases in the ServiceNow AI Platform are critical for managing data and customizing schemas, especially within complex table hierarchies like the Task \[task\] table. They map logical or physical fields to actual database columns, enabling efficient data manipulation and field creation. Understanding storage aliases helps administrators handle table hierarchies and optimize data storage strategies. Show full answer Show less ## Table Hierarchies and Models The Task \[task\] table hierarchy involves two models: * **Table per hierarchy:** Uses a single physical table (Task \[task\]) with a flattened hierarchy where all fields for related tables like Change Request are stored in the task table. This model features glomming, where multiple sibling logical elements share one physical column. * **Table per class:** Used for new tables extending Task \[task\] with over 1 million rows, where each table physically exists in the database and glomming is not applied. ## Storage Alias Definition and Key Fields Each field on a table has a corresponding storage alias defined in the Storage Column Aliases \[sysstoragealias\] table. Key attributes include: * **Element Name:** How the field appears to users and scripts. * **Storage Alias:** The physical column name in the database storing the data. * **Storage Table Name:** The physical table containing the storage alias, which is 'task' for Table per hierarchy and the actual table name for Table per class. * **Table:** The logical class linked to the physical Task \[task\] table column, used as a class discriminator for querying data. For example, multiple logical elements like *cabdelegate* in different classes can share the same physical column alias *aref2* on the Task table, enabling queries that combine the class discriminator and storage alias. ## Functionality and Usage * **Mapping:** Storage aliases connect logical or physical elements to physical database columns, supporting data access and manipulation. * **Glomming:** Allows sibling elements in Table per hierarchy models to share a single physical column, optimizing storage. * **Label mapping:** Associates sysdocumentation labels with elements for better visibility in the UI, reports, and lists. ## Restrictions and Rules * Two logical elements within the same class cannot share the same physical column. * A parent element and its child cannot share a physical column. * Only sibling elements can share a physical column, even if they belong to different child tables of Task. * Fields created directly on the Task \[task\] table cannot be glommed (cannot share physical columns). ## Practical Implications for ServiceNow Customers Understanding storage aliases enables administrators to effectively manage data storage and schema customization in ServiceNow instances, particularly when working with task-related tables. It clarifies how to query and manipulate data in complex table hierarchies, optimize storage by glomming where applicable, and maintain data integrity by following the defined restrictions. This knowledge is essential for advanced data modeling and ensuring efficient database design within the ServiceNow AI Platform. Learn about the role storage aliases play in data manipulation and field creation in the ServiceNow AI Platform. Understanding storage aliases is important for effective data management and schema customization in the ServiceNow AI Platform, particularly when dealing with complex table hierarchies like those in the Task \[task\] table. By default, administrators have access to the Storage Column Aliases \[sys_storage_alias\] table within an instance. However, transactional processes against this table can't be performed by an administrator from the user interface. ## Table hierarchy and models {#storage-aliases__section_ny2_sr1_scc} Understanding storage aliasing requires knowledge of table hierarchies within the Task \[task\] table, which involves two models: Table per hierarchy and Table per class. Table per hierarchy : This model uses a single physical table, the Task \[task\] table, which features a flattened hierarchy where all columns within the task hierarchy exist only on the task table. For example, fields related to change requests aren't on a separate Change Request \[change_request\] table but are integrated into the Task \[task\] table. You can verify whether a table is Table per hierarchy by checking the extension model field in the Tables \[sys_db_object\] table. If the table's parent is a direct child of the Task \[task\] table, the table uses Table per hierarchy.An extended table inherits the hierarchy of its parent. For example, the IMAC \[change_request_imac\] table is a child table of the Change Request \[change_request\] table, which extends the Task \[task\] table. Because the Change Request \[change_request\] table is Table per hierarchy, the IMAC \[change_request_imac\] table model is also Table per hierarchy. Legacy tables such as the Incident \[incident\] table, Change Request \[change_request\] table, and Problem \[problem\] table are all part of the flattened Task \[task\] table hierarchy. Table per class : This model applies to tables that physically exist in the database. It's used for new tables directly extending from the Task \[task\] table when the task row count exceeds 1 million rows. Unlike Table per hierarchy, Table per class doesn't use glomming because it doesn't operate within a flattened hierarchy. ## Storage alias definition {#storage-aliases__section_q1q_zs1_scc} A storage alias is created for every field on a table within an instance. Familiarize yourself with the key fields on the Storage Column Aliases \[sys_storage_alias\] table. Element Name : Indicates how the field appears to users, which is important for user interface interactions and scripting. Storage Alias : Indicates the exact physical column where the data for a field is stored. The storage alias value is used in combination with the table_name value to identify what data to manipulate. The storage alias value is the actual physical column on the Task \[task\] table. Storage Table Name : Specifies the physical table that houses the element. For Table per hierarchy tables, the value is always task. For Table per class tables, the value is the name of the physical table. Table : Specifies the logical class that each element links to on the physical Task \[task\] table. The Table element holds the table_name value which is the class discriminator. Figure 1. Storage column aliases In this example, the storage alias for the cab_delegate element is a_ref_2 and the physical storage table where the data is stored is task. The example depicts 10 logical elements in different logical classes on the Task \[table\] that all link to the same alias a_ref_2 on the physical Task \[task\] table. The sibling elements are glommed, which means they share one physical column on the Task \[task\] table. You can query data from the logical element cab_delegate using a query like: SELECT a_ref_2 from task WHERE sys_class_name='change_request' AND a_ref_2 IS NOT NULL The query specifies data in the physical column a_ref_2. The class discriminator change_request is used in combination with the storage alias a_ref_2 to query the logical element cab_delegate from the logical class change_request on the physical Task \[task\] table. The naming convention for fields created in the actual physical tables can vary depending on the type of field. In this example, a_ref_2 is an alias on the Task \[task\] table that holds values for reference fields. ## Functionality and usage {#storage-aliases__section_lyv_mt1_scc} Storage aliases serve multiple purposes. Mapping : Aliases map logical elements (Table per hierarchy) or physical elements (Table per class) to the actual physical columns in the backend database. The logical element can be glommed to a physical column that is larger than the logical element's max_length. Glomming : Aliases allow multiple sibling elements to share a single physical column in a Table per hierarchy model. Label mapping : Aliases associate sys_documentation (label) records with their respective elements, enhancing visibility in forms, reports, and list views. ## Restrictions and rules {#storage-aliases__section_e14_rt1_scc} * Two logical elements within the same class can't share a physical column. For example, two string fields created on the Incident \[incident\] table can't map to the same physical column in the database. * A parent element and its child can't share a physical column. For example, a field created on the Incident \[incident\] table can't be mapped to a physical column when that physical column is already mapped to a field on the Task \[task\] table. * Only sibling elements can share a physical column. For example, a reference field on the Change Request \[change_request\] table and a reference field on the Incident \[incident\] table and can both map to the same physical column. * Fields created directly on the Task \[task\] table (where sys_class_name is 'task') can't be glommed. {#storage-aliases__ul_ktv_st1_scc}