Feature Suggestion

We need Enate system emails (password resets, notifications, etc.) to be sent using Enate‑managed email infrastructure, rather than routing through our own email gateways. This will improve reliability, reduce configuration overhead on our side, and ensure system emails are consistently delivered without depending on our internal SMTP/M365 setup.

We need Enate to prevent users from typing any “From” address when sending emails. Instead, users should only be able to select from a predefined, validates list of addresses. This will help us stay secure, prevent misuse of email identities, and ensure compatibility with our M365/Graph policies.

Please add native support for sending emails through the Microsoft Graph API within the platform. This would allow teams to leverage modern, secure, Microsoft‑recommended methods for email delivery instead of relying solely on SMTP or built‑in email mechanisms.

We would like (in a specific configuration) to have a auto generated e-mail with different content as is used right now and to have it in 2 language versions (local language and English).

Currently, builder allows process to branch into parallel streams, however these cannot be merged within the same step. This leads to duplication of actions within flows, and (worse) introduction of artificial steps just to Re-merge branches. This feature would better align the product to the ubiquitous BMPN used by most clients.

In Exclusive Mode, customers don’t realise that they need to send in a brand new email for a new request to create a brand new work item. Instead, they write their new request as part of an existing work item thread. They also don’t know that if they want to add information about an existing request, they should reply on the existing email thread so that their email gets attached as part of the existing work item and doesn’t create a brand new one. We need a way to let them know how to reply to emails to express their intent.

Option to delete queues that are not used in configuration in builder.

Would make review/explanation of flow easier to understand and avoid errors.

Binary data (e.g. communications, attachments, Search export files) is managed by Enate and stored in our binary storage locations by default. Clients can alternatively provision their own Azure storage accounts here, and set them as the Active storage location.