> 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-overview.md).

# Task Manager 2.0 - Overview

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.

{% hint style="info" %}
Task Manager 2.0 is not enabled by default. To activate it, please coordinate with your support manager so they can prepare the client environment and turn on the feature.
{% endhint %}

{% hint style="info" %}
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.
{% endhint %}

###  :green\_circle: Task Manager 2.0 :handshake: 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.

{% hint style="info" %}
Record Builder integration is expected to have the default sections enabled. 

The default sections include: Titles, Descriptions, IDs, and Origination.
{% endhint %}

When enabled, the field appears in Ticket editing tables (both Standalone and TV Show Tickets) and behaves exactly according to its RB configuration. Fields limited to specific categories become editable only for those categories in TM. 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.

### :green\_circle: Task Manager Inline-Editing process

Task Manager 2.0 employs a dynamic inline-editing table as the primary interface for Record creation and management. The table is fully driven by Record Builder configuration, meaning that all visible fields, data types, and validation rules are taken from RB settings.

Key characteristics:

* **Row-based record editing:** Each row represents a Record being created or modified within the Ticket.
* **RB-driven columns:** Columns reflect RB-enabled fields and adjust automatically when field configuration changes.
* **Real-time validation:** Required fields, data types, and formatting rules are validated immediately while the user types.
* **Category-based behavior:** Fields appear or become read-only depending on the Record Category selected for the row.
* **Inline controls:** Users can insert, remove, or expand hierarchical nodes (TV Show structures) using row-level menus.
* **Fast data entry:** The spreadsheet-like layout significantly speeds up the creation of complex Tickets or multi-record sets.

This inline-editing model allows users to structure and validate large amounts of metadata quickly and consistently, while ensuring compliance with the data model defined in Record Builder.

### :green\_circle: API Enhancements & Retry Logic

Task Manager 2.0 uses an improved asynchronous API workflow for handling Ticket approvals.\
Instead of creating records during the API request, all work is sent to a background queue and processed asynchronously. Records are created in batches, and any failures are automatically retried several times before being marked as failed. This queue-based approach ensures the system remains stable even during high load or temporary service issues. Users receive real-time updates through WebSocket notifications, and the Background Processing panel shows detailed progress for each operation.This design eliminates API timeouts and ensures long-running tasks are handled safely and independently.

**Batch Execution & Concurrency Control**

Record creation is performed in controlled batches to optimize throughput:

* **Batch size:** configurable (default: 10 records per batch)
* **Concurrency limit:** default: 2 parallel requests per batch
* **Hierarchy awareness:** Show → Season → Episode → Modular Episode → Storyline is processed in correct order

This ensures efficient resource usage while respecting dependencies between hierarchical items.