Concerns about Flow stability, permissions and long-term reliability in Directus 11.13.4

Help
1

Hi Directus team & community,

I’m currently evaluating Directus for a real-world project and I’m running
into serious concerns regarding Flows, permissions and long-term stability.

Environment:

  • Directus version: 11.13.4
  • Docker-based setup
  • PostgreSQL
  • Tested with:
    • Admin user
    • Separate non-admin user
    • Separate policy explicitly created for flows

What worries me most is that the problems appear even with the simplest
possible flows.

  1. These are only very basic flows — and they already fail

At the moment, we are talking about extremely simple flows:

  • trigger on items.create
  • read from a collection
  • create a related record

No complex branching.
No heavy logic.
No performance pressure.

And yet:

  • flows frequently fail with “You don’t have permission to access this”
  • this happens even with explicit read/create permissions
  • even when operations are set to run as “System”
  • even when using a dedicated user + dedicated policy

This raises a fundamental question:
If the simplest flows are already unreliable, how are more complex flows
supposed to behave?

  1. Confidence problem: complexity and future versions

This leads to a much bigger concern than the current bug hunt:

  • How stable are complex flows with many steps?
  • How fragile are flows when Directus is upgraded?
  • How likely is it that small permission or policy changes break existing logic?

Right now, flows feel brittle and hard to reason about.
That makes it difficult to trust them for production-critical automation.

  1. Permissions and policies are opaque in Directus 11

Directus 11 introduced policy-based permissions.
In theory this is powerful, but in practice it is extremely hard to debug:

  • “Admin” does not mean full access
  • The UI often suggests permissions are correct, while the API still returns 403
  • Error messages give no indication which policy, collection or field caused the denial
  • Debugging requires direct inspection of database tables
    (directus_permissions, directus_policies, directus_access)

This is not a reasonable expectation for day-to-day development.

  1. Script operations are misleading

“Run Script” operations are sandboxed:

  • no database access
  • no services
  • no ItemsService
  • no transactions

This makes them unsuitable for real backend logic.
They can only transform payloads.

This limitation is not obvious from the UI and leads to wrong expectations,
especially for developers coming from other systems.

  1. Debugging experience is poor
  • Flow run logs are shallow
  • Permission errors are generic
  • It’s often unclear which operation actually failed
  • Server logs or direct SQL queries are required to understand what happened

This significantly increases development time and frustration.

  1. This is not a misconfiguration issue

To be clear:

  • This was tested with multiple users
  • With explicit policies
  • With explicit read/create permissions
  • With system-level execution
  • On a clean Directus 11.13.4 setup

The issues persist.

At this point the frustration level is very high, because it feels like
the foundation itself is unstable, not just a single misconfiguration.

Questions:

  • Are Flows intentionally limited to very simple, non-critical use cases?
  • Is it expected that any non-trivial automation must be implemented
    as custom extensions or external services?
  • How stable are flows across Directus versions in real production setups?
  • Are there plans to significantly improve:
    • permission transparency
    • flow debugging
    • developer experience around automation?

Right now, it’s hard to trust Flows for anything beyond experiments.

Any clarification would be highly appreciated.

3

Thanks for the clarification — that helps.

My main issue wasn’t whether flows can handle complex logic in theory, but the lack of observability and actionable debugging when permissions or async steps fail. In real-world setups this makes non-trivial automations hard to operate confidently.

For our project we decided to keep flows as triggers only and delegate complex logic (scraping, AI processing, rating logic) to an external backend via webhooks. This gives us better debuggability and long-term stability, while still using Directus as the content backbone.

Glad to hear improvements around permission transparency and flow debugging are on the roadmap.

2

Are Flows intentionally limited to very simple, non-critical use cases?

No, flows are not limited to simple / non-critical use cases.

Is it expected that any non-trivial automation must be implemented as custom extensions or external services?

No, but you can if you prefer doing so.

How stable are flows across Directus versions in real production setups?

Flow logic runs as asynchronous functions with try/catch handling for each step as you would do in a “real production setup”. They are stable and deterministic.

Are there plans to significantly improve:

  • permission transparency
  • flow debugging
  • developer experience around automation?

Yeah! I’m reading between the lines that the real crux here is that you’re running into the limited debug-ability as the main bottleneck. Directus will throw forbidden errors rather than “proper” 404s as a security measure (so we don’t expose the schema to those who shouldn’t know about it), but that severely hinders the ease of use here. Improving that is high on my todo list