Reducing AO Cost by Replacing Email Web Screens with Extensions in OutSystems
73
Views
2
Comments
New
Ideas

In OutSystems, each Email Web Screen is counted as an Application Object (AO), and AOs directly impact licensing cost. In many enterprise applications, we create multiple Email-related Web Screens (for templates, preview, configuration, triggers, admin panels, etc.), which can significantly increase the AO count.

My idea is to replace most Email Web Screens with an Extension-based approach.

Instead of building multiple Web Screens for email management, we can:

  • Handle email generation, templates, and logic inside an Extension

  • Store email templates and configurations in the database

  • Trigger emails via server actions or APIs without requiring dedicated UI screens

How this helps customers:

  • ✅ Reduces AO consumption by eliminating multiple Email Web Screens

  • ✅ Lowers licensing cost for large-scale applications

  • ✅ Centralized email logic in one reusable Extension

  • ✅ Better performance and maintainability for complex email workflows

  • ✅ Reusable across multiple modules and applications

Example Use Cases:

  • Transactional emails (OTP, notifications, approvals)

  • Bulk marketing or system alerts

  • Multi-tenant email templates per client

  • Configurable email rules without UI-heavy admin screens

This approach can help enterprises optimize licensing cost while still keeping email functionality flexible and scalable.

Best is to NOT use the email functionality of OutSystems if you need to send a lot of different emails. External solutions like MailPro, are easy to integrate, have more functionality and are easier to use and scale.

We essentially implemented this solution in our huge insurance platform, putting Email, SMS and Push notification management in to it's own module/app, with the HTML, SMS and Push messages editable in an interface, with field replacement and live previews, so the business could argue about the wording amongst themselves.

It managed all the sending of messages, including the option of tracking push opening so if they customer didn't open the message on their phone, they got an email 6 hours later.  It also automatically delayed non urgent overnight messages until the morning, and prevented duplicate messages. 

The biggest problem was doing the field replacements, which would be very hard to make generic.

It seems like something that could be developed as a forge component.