Listing Type

A Listing-Type in tSM is a reusable configuration object that determines what data is displayed, how it is structured, which operations are available, and which system components consume it. While it serves as the core schema for UI listings, it is equally central for reporting, export/import (backup/restore), notification cards, and widget data sources across the platform.

1. Key Features of Listing-Type Configuration

Entity Assignment Ensures that each Listing-Type is bound to a specific entity (such as Ticket, Customer, or Order), supporting correct data binding, backup/restore operations, and integration with other modules (e.g., notification cards). See configuration, section 4.1, field: Entity Type.
Listing Title Allows you to set a human-readable title (label) for the listing, which appears in the listing header instead of the default or auto-generated name. See configuration, section 4.1, field: Listing Title.
Data Source – ElasticSearch In addition to the standard database source, you can configure the listing to pull data from an ElasticSearch index. See configuration, section 4.1, field: ElasticSearch Index Name.
Default Sorting Enables you to set a default sort field and order (ascending/descending), ensuring records are displayed as expected when the listing loads. See configuration, section 4.1, fields: Sort Field, Sort Order.
Column Definitions Each Listing-Type contains a definition for individual columns, where you configure backend field mappings, UI aliases, visibility, data types, filters, sorting, converters, export options, edit widgets, and permission rules. For more details, see the chapter on Listing Columns.
Profile Management Allows configuration of listing profiles specific to users or groups (including visible columns, filters, and sorting). Users can create, share, and assign profiles as needed. See configuration, section 4.1, tab: Profiles.
Default Filters Supports the application of global (system-level) filters that are invisible to end users, for example, to only display active or B2B records. See configuration, section 4.1, field: Default Condition.
Inline and Mass Editing Supports configuration for in-place (inline) editing of individual fields and bulk editing of multiple records at once, including the ability to link to custom scripts or specialized forms. See configuration, section 4.1, fields: Permission to Edit Input Widget, Enable Mass Editing.
Nested Data Handling Allows flattening and displaying of nested entities (such as tasks within a ticket) as individual rows in the listing, while maintaining parent-child relationships. See configuration, section 4.1, tab: Config.
New Record Form Configuration For entity creation forms opened from a listing, you can define allowed entity types, the default type, the required privilege to create a specific type, and the label of the form itself. See configuration, section 4.1, tab: Config.

2. Working with Entity Metadata

Understanding the underlying data structure is essential for configuring Listing-Type columns, filters, and display options effectively. Discovering available fields and relationships helps you:

Correctly map columns to backend fields.
Set up filters, sorting, and converters according to real data types.
Ensure compatibility with integrations, exports, and UI expectations.

2.1 How to Discover Entity Structure

For ElasticSearch:

You can discover the available data structure by entering the command select searchHit() from <indexName> in the TQL Console. This will display all available fields and information within the selected index.

Example:

select searchHit() from ordering

This command displays the available fields for the “ordering” (orders) index.

For SQL Backends:

In the menu, locate the item tSM Public API.
Select the microservice corresponding to the entity you are interested in.
Choose the API version “v2.”
In the list of API operations, find the GET method for the specific entity.

In the example “200” response, you will find the available fields and structure for that entity as provided by the REST API.

3. Configuration of Listing Type

Configuration of a Listing Type is performed at {{BaseUrl}}/config/listing-type where BaseUrl is your environment address (e.g., https://tsm-demo.datalite.cloud).

Listing-Type settings are divided into five main tabs:

Basic Information – Core properties and identification settings for the Listing-Type
Columns – Configuration of columns, including data mapping, display settings, formatting, and editing options
Profiles – Management of user and group profiles for customized views, filters, and layout preferences
Config – Advanced settings for view modes, nested data structures, and configuration for creating new records
Mass Editing Configuration – Settings that define and control bulk (mass) editing operations, including which fields and actions are available for batch updates

3.1 Basic Settings (Basic Information Tab)

Below is an overview of the all configuration fields on the first tab when creating or editing a Listing-Type:

Name and Code: Each Listing-Type must have both a name and a code.
- The code must be unique among all Listing-Types in the system.
- The name is a human-readable label shown in configuration and in the UI. These identifiers are used throughout the platform for referencing Listing-Types in configuration, API calls, navigation, and profile assignment.
Entity Type: Specifies the main entity (such as Ticket, Customer, or Order) to which this Listing-Type applies. This field is mandatory and is used for data binding, contextual integration (for example, notification cards rely on correct assignment of entity type), and for backup/restore operations (where the system maps each entity to its corresponding Listing-Type).
ElasticSearch Index Name: If the Listing-Type retrieves data from ElasticSearch, specify the name of the ElasticSearch index here. The available indices depend on your environment, but typical examples include: customer, account, lead, person, catalogtree, relationshiptree, inventorytree, ordering, ticket, relatedparty, ticket-template, task-main, log, kafkadlq, notification, registervalue, billing-document, billing-cycle, camundatask.
TQL Name: Technical query name used in TSM Query Language (TQL). This enables integration with reporting, automation, and advanced custom queries.
Listing Title: The human-readable title shown in the listing header (instead of an auto-generated or technical name).
Sort Order: Sets the default sorting state when the listing is loaded in the UI. Options:
- Not Sorted: No default sorting is applied
- Ascending: Sorted ascending by the field specified in Sort Field
- Descending: Sorted descending by the field specified in Sort Field
Default Listing-Type: Indicates if this Listing-Type should be the default configuration for its associated entity. This is important for backup/restore and integrations that use a default Listing-Type if none is explicitly referenced.
Frontend URL: Defines the UI navigation route or target page for this listing. Commonly used for drill-downs from reports or as a target for links.
Backend URL: Specifies the backend API endpoint for fetching or updating records related to this Listing-Type. This is essential for data integrations, REST API calls, notification resolution, and export functionality.
Sort Field: Specifies the field to use for default sorting, in combination with the Sort Order setting.
Default Condition: Predefined filter condition(s) that are always applied to this Listing-Type. These filters are not visible to the end user and are used to restrict or preselect records (e.g., only active items, only B2B customers) and to optimize queries. You can see examples in the INTERACTIVE GUIDE below.
Permission to Edit Input Widget: Specifies the required privilege for using in-place editing in this listing. By default, all users can use in-place editing; if a privilege is specified, only users with that privilege (or any automatically generated column-level privileges) can use the edit widget.
Config Type: A general-purpose categorization field that allows you to group Listing-Types—even those associated with different entities—into a shared category or logical grouping. Commonly used for filtering, selection, and cross-entity configuration in widgets, reporting, dashboards, or other modules where related entities must be handled together.
Enable Mass Editing: Enables or disables mass (bulk) editing operations for this Listing-Type. When enabled, checkboxes are shown next to rows, allowing users to select and edit multiple records at once with batch actions.

INTERACTIVE GUIDE

This example explains the configuration of individual fields for a listing-type in the Basic Information tab.

Detail

Display all tooltips

Entity type:

TQL name:

Sort order:

Config type:

Frontend URL:

Sort field:

Enable mass editing:

Elasticsearch index name:

Listing title:

Permission to edit input widget:

Default listing type:

Backend URL:

Default condition:

Tip: For every Listing-Type, always ensure these primary settings are properly configured and aligned with your use case. They determine not only how data appears in the UI, but also how the listing is used in integrations, reporting, automation, and migration.

4. Summary

Listing-Type is the foundational configuration object that defines what, how, and where data is displayed and used across tSM.
It determines the entity, data source, columns, filters, permissions, display modes, and integration endpoints for each listing.
Properly designed Listing-Types are essential for a consistent UI, secure data access, efficient operations, and robust integrations across the tSM platform.