Summary
In multi-user / enterprise mode, when a user opens a flow URL whose flow lives in a workspace they are a member of but which is not their currently active workspace, the canvas fails to load with:
Failed to retrieve Chatflow ... Chatflow <id> not found in the database!
The user then has to figure out which workspace owns the flow and manually switch to it before the link works. This makes shared flow links between teammates in the same workspace unreliable.
Steps to reproduce
- Run Flowise in multi-user mode with at least two workspaces (e.g. Workspace A and Workspace B), and a user who is a member of both.
- Create a chatflow/agentflow in Workspace A.
- As that user, set the active workspace to B.
- Open the flow's canvas URL directly (
/canvas/:id, /agentcanvas/:id, or /v2/agentcanvas/:id).
Expected: the flow loads (the user is authorized for it).
Actual: Chatflow <id> not found in the database! — the lookup is scoped to the active workspace (B), so a flow in A is reported as not found.
Why this is safe to auto-resolve
chat_flow.id is a globally-unique UUID, so it maps to exactly one owning workspace. If the requesting user is a member of that workspace, the UI can resolve it and switch the active workspace automatically — no manual step needed.
Crucially this must not weaken the existing "Protect Against Cross-Workspace Chatflow Disclosure" hardening: any resolver must return the identical 404 when the user is not a member (or the flow doesn't exist), so it never reveals that a flow exists in a workspace the caller can't access.
Proposed fix
- Backend: a membership-gated
GET /chatflows/resolve-workspace/:id that returns { workspaceId } only when the requesting user is a member of the flow's workspace; every other branch returns the same 404 as getChatflowById.
- Frontend: on the canvas load 404, resolve the owning workspace and — only if it's in the user's
assignedWorkspaces and isn't already active — switch to it and re-fetch the flow, staying on the same canvas URL. Falls back to the normal error otherwise.
I have an implementation ready and will open a PR referencing this issue.
Setup information
- Flowise version: 3.1.x (reproduced against
main)
- Mode: enterprise / multi-user
Summary
In multi-user / enterprise mode, when a user opens a flow URL whose flow lives in a workspace they are a member of but which is not their currently active workspace, the canvas fails to load with:
The user then has to figure out which workspace owns the flow and manually switch to it before the link works. This makes shared flow links between teammates in the same workspace unreliable.
Steps to reproduce
/canvas/:id,/agentcanvas/:id, or/v2/agentcanvas/:id).Expected: the flow loads (the user is authorized for it).
Actual:
Chatflow <id> not found in the database!— the lookup is scoped to the active workspace (B), so a flow in A is reported as not found.Why this is safe to auto-resolve
chat_flow.idis a globally-unique UUID, so it maps to exactly one owning workspace. If the requesting user is a member of that workspace, the UI can resolve it and switch the active workspace automatically — no manual step needed.Crucially this must not weaken the existing "Protect Against Cross-Workspace Chatflow Disclosure" hardening: any resolver must return the identical 404 when the user is not a member (or the flow doesn't exist), so it never reveals that a flow exists in a workspace the caller can't access.
Proposed fix
GET /chatflows/resolve-workspace/:idthat returns{ workspaceId }only when the requesting user is a member of the flow's workspace; every other branch returns the same 404 asgetChatflowById.assignedWorkspacesand isn't already active — switch to it and re-fetch the flow, staying on the same canvas URL. Falls back to the normal error otherwise.I have an implementation ready and will open a PR referencing this issue.
Setup information
main)