Overview
It is common to place a Script Task immediately after a Form Task to process data submitted by Users. However, chaining multiple Script Tasks between one Form Task and the next is not recommended. Although the Script Tasks execute sequentially rather than in parallel, their execution times can add up. As a result, Users must wait for the entire chain to complete before the next Task becomes available, which can negatively impact the End-User experience.
Why Chained Script Tasks Cause Issues
Cumulative Delay Before the Next Task is Available
When Users submit a Form Task, the Request must complete every subsequent Script Task in the chain before the next Task (often another Form Task) is assigned and shown to a User. If each script takes 1–3 seconds, four or five scripts in a row can add up to 10–20+ seconds of dead time between "I click submit" and "I see the next screen" or much longer if any script calls an external system.
No Feedback During the Wait
Unlike Form Tasks, Script Tasks have no User interface. While the chain executes, End-Users typically see a spinner, a blank screen, or nothing at all, with no indication of progress or how long the wait will be. This reads as the application being slow or frozen, even when it is working correctly.
Browser Session Timeouts
If the combined execution time of the chain is long enough, a User's browser session, an API gateway, or a load balancer timeout can be reached before the Request finishes routing to the next Task. This can produce errors that appear to the User as a failure, even though the Process is completing correctly on the backend.
One Slow or Failing Script Blocks the Whole Chain
Because scripts run sequentially, the chain is only as fast as its slowest link, and only as reliable as its least reliable link. A single Script Task in the middle of the chain that calls a slow external API, times out, or throws an error stalls or breaks the entire transition — even if the other three scripts are fast and reliable.
It is Harder to Diagnose Which Step is Slow
When a User reports "the system is slow" after submitting a Form, a long chain of Script Tasks gives support and admins several possible culprits to isolate. Reviewing Request logs to determine which specific script in the chain is responsible for the delay takes more time than it would with a single consolidated step.
Bad Practice
Placing several separate Script Tasks in sequence directly between two Form Tasks so End-Users must wait for the entire chain to complete before the workflow moves on.
Good Practice
Consolidate related logic into a single Script Task. If multiple scripts are just performing related steps of the same operation (e.g., validate data, then format it, then calculate a value), combine that logic into one script rather than splitting it across several sequential Script Task elements.
Move non-blocking work off the critical path. If a step does not need to finish before the user can proceed (e.g., sending a notification, logging, writing to an audit table), do not put it in the User's transition path. Route it to a separate branch off a Parallel Gateway, or trigger it asynchronously (for example, via a Watcher or an external job), to prevent Users from waiting for it.
Use an Interstitial/summary Screen for necessary waits. If real processing time is unavoidable, insert a Screen that tells the User something is happening, rather than leaving them on a blank or frozen page.
Only chain scripts that must run sequentially. If a script's input depends on the previous script's output, sequential order is required — but this is still a reason to combine them into a single script where possible, rather than several separate Script Task elements each carrying the overhead of its own executor invocation.
Monitor and budget execution time for any chain of scripts sitting directly in front of a Task assignment, and set a target maximum (e.g., under 2–3 seconds) for how long a User should wait between submitting one Task and being assigned the next.
Related Information