System Flows e.g. for Invite eMails

[david-zacharias]

Summary

Instead of hard coded business logic in directus source, parts could be transferred to the powerful flows system, allowing users to adapt the logic to their needs. A set of "system flows" would ship with directus - like directus_ system collections to have an out of the box working configuration.

But if needed, the flows / business logic can be modified to match project specific needs (see design details).

Basic Example

One first use cases in mind are the user invite and password reset mails. As stated in #8239, #7372, #16673, #15590, #17485, #3115, and probably more, users have the need for customizing system mails e.g. subject or an i18n body.

A brief example on how this could work for user invite mails:

• Scope of flow Trigger Event Hook would be extend with users.invite, which provides as payload data which was before handed into the template (JWT, and email). Maybe also the role the user gets assigned, or key of the bare user record in the db...
• Directus contains a predefined system flow which is readonly and handles the business logic for sending the emails as currently done in the source (api/src/services/users.ts#L369-L383)
• To modify the business logic, users can duplicate the flow and adapt to their needs
• The system flow would be inactive but could be activated anytime to restore the default functionality

Motivation

This feature could address a wide range of needs and brings new flexibility. One first use cases in mind are the user invite and password reset mails. System flows could enable users to:

• use custom subject (see Add Subject to password request (SDK) #7372, Optional custom invitation's email subject #16673. Custom subject for password reset email #15590)
• make mail body / templates translatable (see Make email templates translatable #8239. Add mail template translations #3115)
• disable invite (e-mails) at all (see How we disable invite user with enable of create user #17099)
• and all the good flows allow already like 3rd party calls, validation, etc.

And some bricks of this idea like duplicating flows are features already requested by users (see #14405)

Detailed Design

I am happy to spend time on a destails system design if the idea in general is of interest.

Requirements List

Must Have:

• Read-Only Flows (aka System Flows)
• Additional Scopes for Flow Trigger Event Hook like users.invite or auth.password.reset
• Migration adding pre-defined system flows

Should Have:

• Support for duplicating flows (Allow duplicating flows #14405)

Could Have:

• tbd

Won't Have:

• tbd

Drawbacks

I am happy to spend time on defining drawbacks if the idea in general is of interest.

Alternatives

Each requirement could be addressed separately in a different scope, like i18n for mails as proposed via translatable apis (see #17485)

Adoption Strategy

I am happy to spend time on an adoption strategy if the idea in general is of interest.

Unresolved Questions

Honestly, a lot. But as said, I am happy to spend time on this if there is a general interest in the idea. Maybe the idea of system flows was already discussed and declined...

[david-zacharias]

@rijkvanzanten I would be happy to get a basic feedback (👍 / 👎 ) whether this idea is of interest or not. Maybe it was already discussed or is against basic principles regarding the direction directus should go.

[rijkvanzanten]

This is a very interesting approach indeed! As of right now, the "services" for the system tables are effectively "just" doing little flow-like steps before using the regular items-service to save to/from the table, so by relying on pre-made flows, we might even be able to remove all of those special services in favor of just having the one! :o

[rijkvanzanten]

I think there's probably a handful of smaller improvements we should add to flows before going into this bigger thing, like the ability to duplicate a flow (so you can easily copy an existing system flow one to get started on your custom additions)

[JonL1]

Migrating every system action to a readable flow and being able to duplicate and change the trigger action to the modified one makes a lot of sense from an internal tool approach.

This is VERY interesting indeed.

[david-zacharias]

This is a very interesting approach indeed!

Happy to hear 😊

I think there's probably a handful of smaller improvements we should add to flows before going into this bigger thing

Absolutely, step by step. If system flows is something directus is looking for in the future, steps can be made in that direction.

Regarding duplication of flows: I haven't seen an RFC yet. I can try to take care of that.

[rijkvanzanten]

Absolutely, step by step. If system flows is something directus is looking for in the future, steps can be made in that direction.

I agree. I don't think this is one of those suggestions that we can just do, as we're talking about pretty intense overhauls of the internal services of the API. We're currently rearchitecting the database abstraction layer itself, so I'm hopeful that rearchitecting the services layer (to have them use flows/hooks) is going to be quite a bit easier once that effort is complete 👍🏻

Regarding duplication of flows: I haven't seen an RFC yet. I can try to take care of that.

That'd be perfect! ❤️

[rijkvanzanten]

Heya! Thanks for opening this feature request!

This feature request has received over 15 votes from the community. This means we'll move this feature request to the Under Review state!

The Core team will schedule a meeting to review this request as soon as possible. The discussion will then be approved or denied. You may or may not be invited to join this meeting with the core team.

For more information, see our Feature Request Process.

[w0kyj]

Consider breaking this into two RFCs:

1. new hook filters/actions
   • user invite
   • user invite accept
   • password reset
   • password reset request
   • 2FA on / off
   • sso ...?
2. system flows