Hello @Ayushi Kumari,

Regardless of the six actions inside the main action triggered by the timer, the main issue you might encounter here is that the timer itself could run into a timeout exception if the logic takes too long to execute.

To handle this, you may need to manage the nested logic itself. I do not know the exact implementation in your case, but for example, if you are updating several records in an entity in one of the six actions, you could add an extra attribute such as IsUpdated or something similar.

This way, if a timeout occurs, you can run the timer again, but this time process only the unprocessed records. For example, the filter could be something like IsUpdated = False.

There is also another approach you can consider, which is encapsulating this logic inside a process (BPT). You can distribute those actions on several automatic activities inside one process.

Hi @Ayushi Kumari ,

It can work, it really depends in your actual use-case, as long as the timer execution finishes before the next scheduled run and you handle failures properly. With 6 long tasks in a single timer, monitoring and troubleshooting also become harder.

A better approach is usually to split independent tasks into separate timers, or keep one master timer that calls separate actions with proper logging and error handling. If the processing is heavy, batching or a queue-based approach is usually more scalable.

Here is an article that can help you design the timer properly:

• How to Manage Heavy Timers in OutSystems

It will "work," but it’s risky. OutSystems Timers are designed for background processing, but they have a default timeout of 20 minutes. If your 6 actions combined take longer than that, the platform will kill the process, and you might end up with inconsistent data or a task that never finishes.

As already said, instead of putting all the logic in one timer, you can use a "Master" timer to trigger others. This isolates failures and avoids the 20-minute timeout.

You case use a Sequential Timers, where if Task 2 depends on Task 1, At the end of Timer 1's logic, use the system action WakeTimer2 or If these 6 tasks are independent, consider Light BPT.

If you decide to stick with a single timer, the Best Practices for "Long Logic", you must implement these two things:

1. Inside your loop, use the DiffMinutes(TimerStartTime, CurrDateTime()) logic. If you are approaching 18 minutes, stop the logic gracefully and "wake" the timer again to pick up where it left off, avoiding the timeout.

2. Use the CommitTransaction action after each of the 6 tasks. This ensures that if Task 5 fails, the work done by Tasks 1–4 is already saved in the database.

It's rick because default timeout of timer is 20mins. 
If there are 6 independent tasks, design them to run asynchronously else u need cover timeout by wake timer/commit transaction/ log result run to check task done/error.

Hi @Ayushi Kumari , 
I am suggesting two options. 
1. Use multiple timers for actions and run parallel.
     For each action one timer and run parallel.
2. Parallel execution using BPT. 

Hi @Ayushi Kumari 

Yes, your implementation will work, but it may not be the best approach if the logic inside the timer is long or resource-intensive.

When you create a single timer in OutSystems and place multiple actions inside the Timer Action, the platform will execute them sequentially. If the total execution time becomes longer than the timer interval, the next execution may be delayed or skipped, which can affect performance and reliability.

A better practice is to keep timers simple and focused. Instead of putting all six long processes inside one timer, you can create separate timers for different tasks. This way each process runs independently, making the system easier to monitor, maintain, and troubleshoot.

Timer - For Large Data Synchronization

Another recommended approach for very long or complex background processes is to use OutSystems Business Process Technology. BPT is designed to handle long-running operations and provides better monitoring and control over process execution.

Also, if your logic processes large amounts of data, consider implementing batch processing. For example, instead of processing thousands of records in one execution, process them in smaller batches. This helps avoid performance issues and improves system stability.

@Ayushi Kumari : Based on one of the screenshot shared earlier, I assume you are trying to offload properties  based on Agreement. A few improvement I could suggest are as follows

1. LTSite action is getting all the sites irrespective of whether there is an entry in Offboarding Entity. If so you will have the same list always. You may consider taking only properties which are not in Offboarding entity. This will limit the list of properties.
2. If LTSite is empty exit the action
3. TWAAgreement8Months - This also returns all the agreements in every execution. Please see if you can sent the property list LTSite so that it will return only the relevant agreement. By doing so you can avoid the loop where listFilter / ListAppend taking place
4. If Step 1 is followed you don't have to  check again in the Offboarding if it exists but can call the Offboarding Case creation.