Global Search for Workflows and Tags - Search recursively through n8n folders

The idea is:

To implement a global search functionality within the n8n interface. This search should allow users to find workflows and potentially tags across the entire n8n instance, recursively searching through all folders and subfolders.

Ideally, the search would index and match against:

  1. Workflow Names: Searching for parts or the whole name of a workflow.
  2. Workflow Tags: Searching for workflows assigned specific tags.
  3. (Optional but highly valuable) Workflow Content: Searching for node types (e.g., “HTTP Request”, “Google Sheets”), specific parameter values (e.g., a URL, an email address, a specific function name in a Code node), or even text within notes added to nodes or the workflow itself.

The search results should clearly display the matching workflow’s name, its full folder path (e.g., Project A / Sub-Project B / Workflow Name), and potentially highlight the matched term (especially if searching content).

My use case:

As n8n usage grows within an organization or for an individual power user, the number of workflows can increase significantly. These workflows are often organized into nested folders for clarity.

  1. Finding Specific Logic: I often need to find a workflow where I implemented a specific pattern, used a certain API endpoint, or configured a particular node (e.g., “Find all workflows using the ‘Specific Legacy API’ node” or “Find where I used the credential ‘Old Service API Key’”). Currently, I have to manually open folders and potentially workflows, which is very time-consuming.
  2. Locating Workflows by Function/Project: Sometimes I remember what a workflow does or which project it belongs to, but not its exact name or location within a potentially deep folder structure. A global search by name or tag (e.g., searching for tag billing or critical_process) would instantly locate it.
  3. Refactoring/Maintenance: When an API changes, a service is deprecated, or credentials need updating, I need to find every workflow using the old configuration. A global content search is crucial for this to avoid missing instances and causing production failures.
  4. Discoverability & Reuse: Finding existing workflows that perform a similar task to avoid rebuilding logic from scratch.

I think it would be beneficial to add this because:

  • Saves Significant Time: Drastically reduces the time spent searching for specific workflows or configurations compared to manual folder navigation.
  • Improves Scalability: Makes managing large numbers (hundreds or thousands) of workflows feasible. Without global search, managing complexity becomes a major bottleneck.
  • Enhances Maintainability: Simplifies the process of updating credentials, API endpoints, or refactoring logic across multiple workflows, reducing the risk of errors and inconsistencies.
  • Increases Productivity: Allows users to find what they need quickly and get back to building or modifying workflows.
  • Promotes Reusability: Makes it easier to discover and reuse existing workflow patterns and logic.
  • Aligns with Standard Expectations: Global search is a standard feature in most development environments, file systems, and content management platforms (like IDEs, operating systems, Jira, Confluence, etc.). Its absence in n8n becomes more noticeable as usage scales.

Any resources to support this?

This is a common feature request reflecting a standard usability pattern found in many software tools dealing with collections of items:

  • IDE Search: Tools like VS Code, IntelliJ IDEA offer powerful project-wide search capabilities (Find in Files).
  • Operating System Search: macOS Spotlight, Windows Search provide system-wide file and content search.
  • Collaboration Tools: Jira, Confluence, GitHub, GitLab all have robust global search features across projects, issues, code, and documentation.

While not a direct resource, the prevalence of this feature elsewhere highlights its utility and user expectation for managing complex sets of information efficiently. Existing forum posts or GitHub issues within the n8n community might also echo this need.

Are you willing to work on this?

Maybe, I may not have the necessary development skills, but I am definitely happy to help with testing and providing feedback. To develop I would need guidance on the n8n codebase.