HI.
I have a screen in my interface that contains a button.
This button triggers an operation that can take up to 10 minutes to complete.
What I want is that, while the operation is running asynchronously in the backend, a progress bar is displayed on the screen.
I was able to achieve this by starting a backend process while updating the progress bar on the frontend.
However, the problem is that OutSystems processes have a fixed timeout of 6 minutes, and when the operation takes longer than 6 minutes, an error occurs.
I considered using timers, but a timer only runs one instance at a time, so it would not be possible to run it simultaneously from two different frontends.
Is there another way to run asynchronous executions in OutSystems?
In OutSystems, what’s hitting you isn’t really "async vs sync", it’s the Automatic Activity (BPT) execution timeout.
1) Why does your BPT approach fail after ~5–6 minutes
BPT Automatic Activities have a hard timeout (typically 5 minutes), and it’s not configurable. If the work inside an Automatic Activity runs longer, the platform will terminate it.
So, the right pattern is not to execute the heavy work inside BPT Automatic Activities. Use BPT only to orchestrate, if you need process audit/history.
2) Recommended pattern for 10-minute jobs + progress bar
Use a Job Queue entity + Timer worker(s):
On button click (UI)
Create a Job record (Id, RequestedBy, Status, ProgressPct, StartedOn, UpdatedOn, Payload, ErrorMessage, etc.)
Return the JobId immediately to the screen.
Background execution (Timer)
Timer picks the next Job in Queued state.
Marks it Running.
Processes in chunks (e.g., 1,000 rows per iteration, or "step 1/step 2/step 3" …).
After each chunk, updates ProgressPct + LastMessage.
If it’s not finished, it can continue next run or even Awake itself to run again soon (still respecting the "one instance per timer" rule). Timers are the intended mechanism for long running async work.
Progress bar (UI)
UI polls every X second (client-side interval) calling a small server action like GetJobStatus(JobId) that reads the Job record and returns ProgressPct/Status/Message.
Bind that to the Progress Bar pattern.
This is also the most common answer in our community: persist state in an entity and have the screen poll it.
3) "But a timer only runs one instance at a time…"
Correct: the same Timer never runs more than one execution concurrently.
That does not prevent multiple users/frontends from starting jobs. They all just enqueue jobs, and your Timer processes them.
4) Key design tip
Make each timer execution safe to resume:
Best, Miguel
great detail
Break the backend logic flow into multiple automatic activityif possible. You can send outparameter to the next automatic activity. You can reduce the load on a single automatic activity and achive the scope with BPT.