Upper limits for simulation: Causes and solutions
Upper limits act as safeguards to prevent simulations from running indefinitely or producing unrealistic results. They are triggered when certain thresholds are exceeded, usually due to modeling errors such as infinite loops, incorrect arrival times, or resource overloads.
Below, we review each of the upper limits. For each of them, we indicate the corresponding default value. To increase any of the upper limits, please raise a ticket in the support desk.
Maximum number of BPMN elements to be processed in a simulation:
Default value: 2000000.
Description: This is the maximum number of BPMN elements (including BPMN events, tasks, gateways) that may be traversed in one simulation run.
Error message displayed: “Maximum number of elements allowed to simulate across all process instances reached.”
Possible causes
High-recurrence rework loop.
A common cause of exceeding the limit is a rework loop that almost always sends cases back for reprocessing. For example, if a gateway sends 99.99% of cases back to the rework task and only 0.01% forward, nearly every case repeats rather than progressing to the end. As more cases are added, the number of loop iterations grows, creating an exponential build-up of events.
How to fix:
Lower the rework probability (e.g., from 99.99% to a realistic rate).
Consider reducing the number of cases to be simulated.
Set the simulation to run by duration rather than number of cases.
Tip
If the upper limit is not reached, but the simulated log shows an unusually large number of activity instances, reduce the number of simulated cases and rerun the simulation. This produces a log with fewer cases. In this smaller log, open the Case Inspector in Process Discover to identify activities that repeat indefinitely. This will reveal where a near-infinite loop exists. We can then adjust the branching probabilities in the BPMN Editor.
A rework that occurs continuously due to an unchanging case attribute.
A rework loop will run endlessly if its condition depends on a case attribute that never changes. For example, suppose Task C routes back to rework whenever the amount attribute is less than or equal to 40,000.
If this attribute remains fixed at 40,000, the condition will always be true, so every case has this repeated rework.
How to fix:
Review the rework condition and check that it uses an attribute that can change during the simulation.
If the attribute is static, update the model so that another task modifies it.
Maximum length/duration of the simulation
Default value: 5 years.
Description: This is the maximum period of time that a simulation run may cover.
Error message displayed: “The timeframe for this simulation exceeds the limit (5 years).”
Possible causes
Intense resource bottleneck
A simulation can exceed the 5-year time limit when tasks take much longer to process than new cases take to arrive. This mismatch causes queues to grow rapidly.
For example, if a task requires 2 days to complete but new cases arrive every 1 minute, the backlog grows faster than the resource can process them.
Over time, the process becomes bottlenecked, and the simulation time will keep on increasing.
Extremely long task durations
If a task takes months (e.g., 6 months), the total duration of the simulation can easily go beyond the limit.
How to fix:
Reduce extreme processing times
Add more resources (FTEs) to the task with high processing time.
Consider simulating by duration instead of by case count when appropriate.
Maximum period to generate new process instances
Default value: 1000 days.
Description: This is the maximum period of time in a simulation run during which new cases may be created.
Error message displayed: “Arrival rate too long – process instances started over maximum allowed period.”
Possible cause: This can happen when the interarrival time is large (e.g., 150 days), combined with a high case count.
How to fix:
Shorten the interarrival time so the same number of cases is created faster.
Reduce the number of cases.
Run by duration, so we determine how many cases fit into the period.
Maximum tasks in a single resource queue
Default value: 10000 activities.
Description: This is the maximum number of pending activity items that may be assigned to a given resource.
Error message displayed: “Maximum task queue size limit reached for a resource.”
Possible cause: This can occur when the processing time for a task is long, the number of resources assigned to it is small, and the interarrival time is short. Tasks are added to the resource queue faster than they can be completed.
How to fix:
Increase the number of resources assigned to the task, so that work is shared.
Slow down arrivals (increase the interarrival time) or reduce processing time where realistic.
Maximum process instances (cases) per scenario
Default value: 20000 cases.
Description: This is the maximum number of process instances (cases) that can be simulated within a single scenario.
How to fix:
When simulating by case count, lower the requested cases (the UI typically prevents entering an out-of-range value).
If simulating by duration, shorten the duration or increase the interarrival so fewer cases are created in the period.
Maximum number of resources
Default value: 1000 resources.
Description: This is the maximum number of resources that any given role may have.
Error message displayed: “Allowed number of resources in one pool exceeded.”
How to fix: Reduce the number of resources.
Maximum number of roles
Default value: 1,000 roles.
Description: This is the maximum number of roles that can be defined within a single scenario.
How to fix:
Merge similar roles into a single role where possible.
Reduce the role definitions.