In one of our production apps, we currently send emails directly from the main process models using the Send Email smart service.
As volume is increasing, we’re starting to rethink whether this is the best long-term approach.
For those who’ve worked on larger implementations — do you keep email logic in the main process, or move it to a reusable subprocess? Also curious how you’re handling retries and basic monitoring in production.
Just trying to sense-check our design as the app scales.
Discussion posts and replies are publicly visible
Arunkumar Arumugam said:do you keep email logic in the main process, or move it to a reusable subprocess
A reusable process having send email node with parameters like to,cc,attachmnets, body,subject etc. Only if there is a specific email template is there not inline with generic emails we send then that node is put directly in respective process model. Otherwise we use the reusable sub process.
I would also opt for a reusable model. It makes it easy to enforce using certain templates or other settings like sender email.
Keep email logic in a reusable utility subprocess with standard inputs/outputs, and keep main process models focused on core business flow. Main process triggers email subprocess asynchronously, subprocess handles retries and logs failures separately.
Thanks everyone, this is helpful.
We’re moving toward a centralized async email utility subprocess so the core models stay focused on business flow.
We’ll standardize sender/template config there and contain retries + failure logging within that layer.
Appreciate the insights.