> For the complete documentation index, see [llms.txt](https://handbook.n8n.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.n8n.io/how-we-build/governance-and-ownership/manifest.md). # Manifest: Workflow visibility and management ![](https://1295977995-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FikYvt5xWzvK7NtuHBUPD%2Fuploads%2Fgit-blob-4922fb465d2e7337db71f8590111730f79866f21%2Fmanifest-editorial.png?alt=media) This page explains how the Automation team uses Manifest to understand, govern, and maintain workflows across n8n instances. ## What Manifest is Manifest is a **read-only observability and management layer for n8n**. It brings workflow metadata from multiple n8n instances into one place so teams can understand what exists, who owns it, how workflows depend on one another, which services and credentials they use, and where cleanup or consolidation may be needed. Current capabilities include: * Cross-instance workflow visibility. * AI-generated descriptions that make workflows easier to understand. * Dependency mapping, including sub-workflows and shared error workflows. * Visibility into ownership, services, and credential usage. * Execution-consumption insights. * Cleanup signals for duplicate, inactive, or potentially unnecessary workflows. Manifest is **read-only against n8n**. It can surface findings, but it does not create, change, disable, or delete workflows. ## How Manifest supports the build lifecycle Use Manifest before and during a build to understand the existing automation estate, not as a replacement for designing or documenting the workflow. 1. **Check before building.** Search for existing workflows that already solve the problem or could be extended or reused. 2. **Understand dependencies.** Review connected workflows, services, credentials, and likely failure impact before changing an existing automation. 3. **Build clearly.** Use meaningful workflow names and establish ownership so the automation can be understood outside its original project context. 4. **Review after sync.** Find the workflow in Manifest and review its generated description, detected dependencies, ownership, and service usage. 5. **Resolve findings in the source.** Make required changes in n8n; Manifest itself remains read-only. 6. **Support handover.** Use the Manifest record alongside the project documentation to help a future maintainer discover and understand the workflow. Manifest helps answer **what exists and how it connects**. The project documentation should still explain **why the automation exists, how it should be operated, and what to do when it fails**. ## When to use it Manifest is useful when: * A project may overlap with existing workflows. * A change could affect downstream workflows or shared services. * Ownership is unclear. * The same service or credential is used across several automations. * A team is preparing for handover, review, consolidation, or retirement. * Multiple n8n instances make discovery difficult. ## Guardrails * Treat AI-generated descriptions as a useful first pass and review them before relying on them. * Do not record secrets in documentation or workflow metadata. * Verify findings in the live workflow before making a high-impact decision. * Manifest is exploratory; capabilities and operating guidance may change as the product develops. ## Resources * [Open Manifest](https://manifest.n8n.io/) * [Manifest README](https://github.com/n8n-io/manifest/blob/main/README.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://handbook.n8n.io/how-we-build/governance-and-ownership/manifest.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.