Hello everyone,
I am working on a requirement where I need to send notifications to a very large user base, and I would like guidance on the best OutSystems approach.
Requirement details:
I have approximately 1 million subscribers.
A notification must be sent to all subscribers on the 1st of every month using an OutSystems Timer.
Due to the high volume, it is possible that some subscribers may not receive the notification during the first timer execution (timeouts, failures, limits, etc.).
After the first timer cycle completes, I need to re-run the process only for the remaining subscribers who did not receive the notification.
The retry process should continue until all eligible subscribers receive the notification (or until a retry limit is reached).
What I am looking for:
Best practices to handle large-volume notification processing in OutSystems.
Recommended Timer design / batching strategy for 1 million records.
How to safely track sent vs. pending subscribers to avoid duplicate notifications.
I implemented my logic, i dont know whether is correct or not, i am attaching my file just go through my file.
Any guidance, sample architecture, or real-world experience would be greatly appreciated.
Thank you in advance.
Hi @Sagar Andhyal ,
Here is a step-by-step guide that can help you: How to Manage Heavy Timers in OutSystems .
Now, based on your current implementation, I’d recommend a few adjustments:
Remove CommitTransaction from inside the loop. Since you aren’t doing any Create/Update/Delete in the loop, there’s nothing to commit.
Process subscribers in batches by setting a maximum number of records in your GetSubscribers aggregate. This keeps each Timer execution short and more reliable.
If you want the simplest possible implementation, you can add a LastNotifiedOn attribute on Subscriber and filter by month/date, but be aware this is less robust for crash/retry scenarios and doesn’t support multiple notification types cleanly.
Add proper logging and error handling. Use LogMessage and handle exceptions so you can clearly identify whether the Timer ended successfully, aborted due to time limits, or failed due to an error. This will make troubleshooting much easier.
You could use Site properties instead of hardcoding values.
Hi @Sagar Andhyal
To handle notifications for a very large user base in OutSystems, it is important to avoid processing all records in a single Timer run.
The recommended approach is to separate scheduling from processing. A monthly Timer should only create notification records with a Pending status. A second, frequently running Timer should process these records in small batches .
Each notification record should track its status (Pending, Processing, Sent, Failed) and retry count. The processing Timer updates the status to Sent on success or retries failed records until a maximum retry limit is reached.
This design ensures scalability, fault tolerance, and no duplicate notifications, even if the Timer execution fails or times out.