Appian Community and Appian Academy are being upgraded. As a part of the upgrade, Appian Community is currently in read-only mode, and user registration is disabled until August 3. We apologize for any inconvenience this may cause, but a more secure, stable, and performant Community experience is coming soon!
The new Appian Community launches August 3, followed by Appian Academy on August 7. During the migration, Appian Community Edition, Appian Academy, Documentation, Certifications, Instructor-led Customer Training, Partner Sales Training & Accreditation, and Forum (for Appian Partners and Customers only) will remain available.
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
Unknown 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.