As of now you can get that info from the DB with the query like:
select
w.id,
w.name,
w.active,
w.wf_nodes->>'name' as ExecFunctionName,
w.wf_nodes->'parameters'->>'workflowId' as executedWF
from (
select id,name,active,json_array_elements(nodes) as wf_nodes
from workflow_entity
) w
where w.wf_nodes->>'type' = 'n8n-nodes-base.executeWorkflow' AND w.active::bool = true
order by id asc
Another related suggestion: a button or link in the Execute Workflow node to pop open the workflow dependecy would be convenient. It’d help navigate throw the actual execution flow.
This resonates with a problem I’ve been exploring too.
I’m building Fluxpect, an external change-intelligence layer for n8n teams. It is not a replacement for an in-editor workflow dependency graph, but a complementary layer: it maps external vendor dependencies to workflows, monitors relevant public source changes, and helps show which workflows and clients may need review before something breaks in production.
The workflow-to-workflow dependency graph described here would make that operational picture even stronger.
I’m currently looking for a few n8n teams to test the beta and give candid feedback. I’d especially like to understand which dependency relationships and change signals would be most valuable in day-to-day operations.
If this is relevant to your team, I’d be happy to compare notes: