> For the complete documentation index, see [llms.txt](https://knowledgebase.fabricdata.com/fabric-knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledgebase.fabricdata.com/fabric-knowledge-base/learn-the-application/destinations/task-manager/task-manager-2.0-features.md).

# Task Manager 2.0 Features

> Task Manager 2.0 is not included in the default set of Fabric system features.\
> Please contact your support manager for more information.

> All Task Manager documentation has been revised to include the updates and enhancements delivered in Task Manager 2.0. \
> For any further details or support, please reach out to your support manager.

Task Manager 2.0 is a unified system for creating, validating, and preparing content records before they are approved and pushed into the internal working platform. It provides an end-to-end workflow that enables managers to create Tickets, add and edit Records inline, enforce field rules defined in Record Builder, and maintain both simple and complex content structures such as Standalone titles and full TV Show hierarchies.

TM 2.0 integrates tightly with **Record Builder**, using its field configuration, validation rules, and category applicability to shape how Records are created and edited. Users can also leverage bulk actions such as multi-select, collection assignment, Nuvo import, and inheritance (for TV structures) to speed up content preparation.

Once a Ticket is ready, it goes through an approval workflow. Approved Tickets are exported to the internal system, ensuring consistent and controlled content creation across the platform.

#### Record Builder integration

Record Builder serves as the central configuration layer for Task Manager 2.0.\
All field logic—visibility, required/optional rules, category mappings, data types, validation, and naming—is controlled in RB and automatically propagated into TM 2.0 when the *“Include in Task Manager · Record Create Request”* toggle is enabled for that field.

When enabled, the field appears in Ticket editing tables (both Standalone and TV Show Tickets) and behaves exactly according to its Record Builder configuration. Fields limited to specific categories become editable only for those categories in Task Manager. Mandatory fields must be filled before submission. Any updates in RB—such as renaming fields, changing validations, or adjusting category applicability—are reflected in TM after reload.

This integration ensures a single, consistent data model across the entire content workflow.

All Record Builder rules are applied on API side. If user uses API need to follow common rules.

<figure><img src="https://1453363788-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPS7xvtVOuEwjKjl1m1Xs%2Fuploads%2F6QiVdVfJYOsfekAQUklP%2FScreenshot%202025-11-12%20at%2017.42.33.png?alt=media&amp;token=27e94647-9f6a-43e0-b760-adf748fa69d4" alt=""><figcaption></figcaption></figure>

#### Inline-editing records table

Task Manager 2.0 introduces an inline-editing table that enables quick, efficient creation and editing of Records. Instead of opening modal windows or separate forms, users work directly in a grid where each row represents a Record and each cell corresponds to a field defined through Record Builder. The table provides real-time validation feedback, category-based field applicability, and inline controls for adding, removing, and organizing Records. This design significantly improves workflow speed and reduces friction when handling complex or multi-record Tickets.

<figure><img src="https://1453363788-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPS7xvtVOuEwjKjl1m1Xs%2Fuploads%2FkGTL3kpdO2gJ7oqDc73R%2FScreenshot%202025-11-26%20at%2018.22.42.png?alt=media&amp;token=e644c28f-303e-4e26-826e-1f79068797f9" alt=""><figcaption></figcaption></figure>

#### API enhancements

Task Manager 2.0 uses an event-driven API architecture with asynchronous background processing, batch execution, concurrency controls, and automatic retry logic. Record creation tasks are handled independently in a queue worker, with real-time WebSocket updates and detailed tracking in the Background Processing panel. Transient failures are retried up to three times, ensuring high reliability and preventing Ticket-level failures.