Jump to content

Connect SuperML | Leeroopedia MCP: Equip your AI agents with best practices, code verification, and debugging knowledge. Powered by Leeroo — building Organizational Superintelligence. Contact us at founders@leeroo.com.

Principle:FlowiseAI Flowise Chatflow Listing

From Leeroopedia
Revision as of 17:21, 16 February 2026 by Admin (talk | contribs) (Auto-imported from principles/FlowiseAI_Flowise_Chatflow_Listing.md)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Attribute Value
Source Repository FlowiseAI/Flowise
Domain Chatflow_Creation
Workflow Chatflow_Creation
Last Updated 2026-02-12

Overview

Technique for retrieving and displaying paginated lists of chatflow configurations from a server-side store. This principle covers the pattern of fetching chatflow records with pagination (page, limit), filtering by type (CHATFLOW), and rendering as a card grid or list table. It solves the problem of organizing multiple AI workflow configurations for user navigation and management.

Motivation

In any visual AI agent builder, users accumulate numerous chatflow configurations over time. Without a structured listing mechanism, navigating and managing these configurations becomes unwieldy. A paginated, filterable listing view provides:

  • Scalability -- Server-side pagination ensures that only a bounded subset of records is transferred per request, keeping the UI responsive even as the total number of chatflows grows.
  • Organization -- Filtering by type (e.g., CHATFLOW vs AGENTFLOW vs MULTIAGENT) allows the UI to present purpose-specific views.
  • Discoverability -- Card grid and list table layouts give users multiple ways to browse and locate the chatflow they need.

Description

The Chatflow Listing principle employs a standard CRUD list-read pattern with server-side pagination. The client-side component sends query parameters (page number and page size limit) to a REST endpoint that returns a bounded result set. The server responds with an array of chatflow records plus a total count, enabling the client to render paginator UI controls.

Request Flow

  1. The UI component mounts and dispatches an API request with optional pagination parameters: { page: number, limit: number }.
  2. The API client appends a type filter (?type=CHATFLOW) to the request URL to restrict results to chatflow-type configurations.
  3. The server returns a response containing the matching records and the total count.
  4. The UI renders the records as either a card grid (visual thumbnails) or a list table (tabular rows), depending on user preference.
  5. The paginator component uses the total count to calculate page boundaries and allow navigation.

Data Shape

The server response follows this structure:

{
  data: Chatflow[],   // Array of chatflow records for the current page
  total: number        // Total count of matching records across all pages
}

Each Chatflow record includes fields such as id, name, flowData (serialized graph JSON), type, deployed, createdDate, and updatedDate.

Theoretical Basis

This principle is grounded in the standard CRUD list-read pattern with server-side pagination. The approach is characterized by:

  • Offset-based pagination -- The client sends page and limit parameters. The server computes an offset (page * limit) and returns limit records starting from that offset. This is the most common pagination strategy for administrative listing views where random page access is needed.
  • Type filtering -- A query parameter constrains the result set to a specific entity subtype. This avoids over-fetching records that belong to a different workflow category (e.g., agent flows).
  • Separation of concerns -- The API client encapsulates the HTTP details (URL construction, query parameter serialization), while the UI component focuses on rendering and user interaction. The pagination state is managed at the component level, decoupled from the API layer.
  • Total count for paginator -- By returning the total number of matching records alongside the current page, the server enables the client to render accurate paginator controls without an additional count query.

Usage

Use this principle when building a listing view of saved chatflow configurations with pagination and filtering. It applies to any scenario where:

  • Multiple chatflow records need to be presented to a user for selection or management.
  • The dataset may grow large enough to require server-side pagination.
  • Different chatflow types (CHATFLOW, AGENTFLOW, MULTIAGENT) need to be displayed in separate views.

Related Pages

Page Connections

Double-click a node to navigate. Hold to expand connections.
Principle
Implementation
Heuristic
Environment