Types of timeouts in WEBCON BPS

Applies to version: 2022 R1 and above; author: Konrad Keppert

Related documentation

A detailed description of the functionalities mentioned herein and their configuration can be found in the following sections of the WEBCON BPS Help:

• Actions | WEBCON BPS
• Automations | WEBCON BPS
• Services | WEBCON BPS

Introduction

A short response time ensures a smooth and comfortable experience for end users. However, some operations may take too long to meet this expectation. This can result from suboptimal configuration, an excessive amount of data to process, insufficient infrastructure, or—more rarely—system anomalies. To address this, execution time limits (timeouts) are enforced for individual operations. These bring several benefits:

• informing the user when an operation takes too long and stopping unnecessary waiting,
• freeing up server resources,
• preventing system modules from freezing.

WEBCON BPS is no exception in this regard. This article aims to outline timeouts based on example scenarios across the following areas:

• automations,
• operations performed by the service,
• HTTP requests,
• T-SQL transactions,

It highlights which of these limits are configurable and which are determined by the underlying infrastructure.

The article does not cover limits that may affect the behavior of WEBCON BPS but originate from external infrastructure components (e.g., proxy servers).

Actions

SQL Queries

SQL queries are the foundation of the vast majority of operations performed within the WEBCON BPS platform. In addition to non-modifiable system queries—such as retrieving the current user’s data or updating task counters—users can define their own queries in many areas of WEBCON BPS Designer Studio. These user-defined queries are subject to a fixed, non-configurable timeout limit of 30 seconds.

Regardless of whether a query is placed in a Change value of single field, Update item list values, or Add attachment action—if the SQL query does not complete within the given time frame, the user will receive the error message: “The wait operation timed out”, and the automation will be rolled back.

A simple scenario to reproduce this behavior involves placing the Change value of single field action on a path transition, where an SQL COMMAND rule executes for longer than 30 seconds. For testing purposes, the WAITFOR DELAY command can be used, as shown in the screenshot below.

Fig. 1. Configuration of an action that will not complete within the timeout limit

When a user completes a task on a path that includes such an action, the following message will appear, the path transition will be interrupted, and all other actions within the automation—even if executed successfully—will be rolled back.

Note: Rolling back actions within an automation does not undo any changes made in external systems as a result of integration (e.g., an entry created in SAP using the Invoke REST web service action).

Fig. 2. Message indicating that the SQL query in the action exceeded the timeout limit

HTTP requests

HTTP requests can be divided into two categories: those defined by users in the Invoke REST web service action and the system-generated requests, which are not configurable and are triggered depending on the functionalities being used.

The execution of the Invoke REST web service action is forcibly terminated after 100 seconds. Operations that time out in this way return the error message: "A task was canceled." All timeouts in this category are non-configurable.

The second group includes integrations based on Microsoft Graph, such as OneDrive and Exchange actions, data retrieval from HotMailBox/MailApproval mailboxes, or user synchronization with Entra ID. These requests also have a 100-second timeout.

An exception is the request sent to Microsoft Graph to obtain an authentication token, which has a timeout of 120 seconds. This request is sent before establishing a connection—for example, at the beginning of user synchronization with Entra ID.

Automations

The configuration of an automation includes a parameter called Execution time limit, which is accompanied by the following contextual help:

This parameter defines a time limit (in seconds) for the automation to complete. Exceeding this time limit will interrupt the automation with the "Execution time exceeded" error.

The duration of the automation is calculated from the beginning of its execution and is checked before entering each automation block (action block or process automation block).

A key detail is that the timeout is evaluated before entering each block.

To illustrate this behavior, a test automation was created containing three Change value of single field actions, each taking 6 seconds to execute. The execution timeout for the automation was set to 10 seconds.

Fig. 3. Example of an automation with multiple actions and a short execution timeout

Execution times for actions and automations are evaluated as follows:

1. Before “Action 1” begins, the total automation time is checked – it is 0 seconds.
2. “Action 1” executes and takes 6 seconds.
3. Before “Action 2” begins, the total automation time is checked – it is now 6 seconds.
4.  “Action 2” executes and takes another 6 seconds.
5. Before “Action 3” begins, the total automation time is checked – it is 12 seconds.
6. The configured timeout limit (10 seconds) has been exceeded, so the automation is terminated and an error message is displayed to the user.
    

Fig. 4. Message indicating that the automation execution timeout has been exceeded

In the instance History, it is recorded that two actions in the path transition automation were completed successfully, but the third one failed. This caused a rollback and prevented the instance from being saved.

Fig. 5. Logs of the interrupted automation in the instance History

In the logs for “Action 3”, the reason for the failure is clearly indicated:

"Execution time exceeded."

Fig. 6. Logs of an action interrupted due to exceeding the automation timeout

What would happen if, in the above example, the automation timeout had been set to 15 seconds? At the moment “Action 3” begins, the total duration of the automation is 12 seconds—less than the configured limit—so Action 3 would execute successfully. This means that even though the total execution time of all actions would be 18 seconds, and the timeout was set to 15 seconds, the automation would still complete without errors.

Note: The automation timeout and the action-level timeouts (described in the previous section) apply simultaneously. This means that if an individual action exceeds its own timeout (e.g., due to an SQL query running longer than 30 seconds), the automation will be terminated and rolled back—even if the automation-wide timeout has not been reached.

Workflow Service

Services operations timeout in seconds

This parameter defines the maximum number of seconds allowed for operations executed by the Workflow Service, which includes:

• timer-based actions,
• cyclical actions,
• handling of HotFolders and HotMailBoxes (monitoring, starting instances, attaching to instances based on barcodes),
• default path transitions from steps such as Text layer, OCR AI, and OCR AI Learn,
• path transitions triggered by the MailApproval feature.

By default, the limit is set to 120 seconds, but it can be adjusted in the Designer Studio Service Configuration. A detailed list of functionalities covered by this limit is available in the contextual help.

To demonstrate how this timeout works, the following configuration was used:

• the service execution time limit was set to 60 seconds,
• a cyclical action was added and configured to run within a transaction,
• the Move workflow (SQL) action was added to the automation,
• the action was set to move 4 instances, each with a comment being added,
• each path transition for an individual instance takes 18 seconds.
   

Fig. 7. Example configuration of a cyclically executed action

The total execution time of the action was approximately 72 seconds (4 transitions × 18 seconds). The timeout limit was set to 60 seconds. Although each individual path transition would have completed successfully on its own, the service exceeded its allocated time limit, and the operation was terminated.

In the execution logs of the cyclic action, the following message appears:

Operation was withdrawn

The task was canceled.

In the same log entry, a detailed error message confirms that three out of four path transitions were completed successfully, but the total execution time exceeded the defined timeout:

Number of instances to move: 4.

Instance with an ID 220 and a number Main/2025/02/00001: moving status: Workflow instance has been updated.

Instance with an ID 206 and a number Main/2024/11/00003: moving status: Workflow instance has been updated.

Instance with an ID 205 and a number Main/2024/11/00002: moving status: Workflow instance has been updated.

The operation has timed out or the operation was canceled by an administrator or WEBCON WorkFlow Service due to a configuration change or failover.

Operation was withdrawn

Since the action was executed within a transaction, a rollback occurred—ultimately, none of the instances were updated. As confirmation, it was verified that none of the moved instances contained the expected comment.

Fig. 8. Result of a transaction rollback caused by exceeding the service operation timeout

OLAP query execution timeout in seconds

OLAP (Online Analytical Processing) queries are executed according to the schedule defined by the KPI time refresh parameter. These queries are necessary for collecting step-based statistics and calculating KPI metrics defined in process configurations. The execution timeout for OLAP queries is fixed at 7200 seconds (2 hours) and cannot be configured.

Fig. 9. Parameter value in Designer Studio

PowerShell action command execution timeout in seconds

This defines the maximum time allowed for executing the Run a PowerShell script action. The timeout is 60 seconds and is non-configurable.

Fig. 10. Parameter value in Designer Studio

If this timeout is exceeded, the user will see the following message (which is also logged in the action’s execution history):

Error in On path action Run a PowerShell script. (Step: Start, path: Force a timeout) 

The request channel timed out attempting to send after 00:01:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. 

The HTTP request to 'http://kt01:8002/WorkFlow/WCFService' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout.

This error message occurs because the HTTP request is passed from WEBCON BPS Portal to the WEBCON Workflow Service, which is responsible for executing PowerShell scripts. A similar message may appear when other requests passed from the Portal to the Workflow Service time out—such as those related to license service data retrieval.

Note: Exceeding the PowerShell action timeout does not terminate the script's execution on the server. Even though an error message is displayed and the automation is interrupted, the PowerShell script continues to run in the background. For example, if the script is adding rows to a SQL table in a loop and the entire operation takes longer than 60 seconds, the script will continue inserting rows even after WEBCON BPS reports a timeout error at the 60-second mark.

Number of seconds allotted per SQL operation during SOLR indexing

When the Workflow Service receives a task to index a workflow instance in the SOLR search database, the first step is to execute an SQL query that retrieves the instance data (form data, Item lists, permissions, attachments) from the database. Based on this data, an XML file is generated and sent to SOLR.

This parameter defines the timeout for executing that SQL query. By default, it is set to 300 seconds, but the value can be modified.

Number of seconds allotted per operation when connecting to SOLR server

Once the XML file (or multiple files, in the case of process or database reindexing) is prepared, the Workflow Service sends an HTTP request to the SOLR API, waits for the documents to be processed (indexed), and expects a response from the SOLR server. This parameter defines the amount of time the Workflow Service will wait for a response confirming successful request processing. The default value is 300 seconds, and it can be changed.

Number of seconds for text extraction from attachment file (applies to 2024 R1 and above)

If the option Add attachment content to SOLR search index is enabled in the process configuration, then—in addition to form data—the text content of attachments is also sent to SOLR for search purposes. To support this, the Workflow Service must extract a text layer from the file attached to the workflow instance (similar to the Add a text layer action). This parameter defines the maximum time allowed for text extraction from a single file. It is non-configurable and set to 60 seconds. If this limit is exceeded, the Workflow Service logs and the SOLR indexing queue will contain the following message:

"Text extract timed out after 60 seconds."

Since version 2024 R1, attachment content is indexed independently of individual workflow instances, meaning that receiving this error does not necessarily imply that the corresponding workflow instance will not be updated in the search database.

Reports

Loading data into reports available within applications has a non-configurable timeout limit set to 60 seconds. If the query that retrieves the data does not complete within this time, the user will see the following message:

Fig. 11. Error message displayed to the user when report data retrieval fails

While the message suggests that performance issues may be caused by non-optimal calculated columns, the real cause is often a slow SQL Server (e.g., outdated statistics) or an excessive volume of data to load.

SQL queries that exceed the timeout can be captured in a diagnostic session. Once the error is registered, the session will contain a node labeled: "Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding." It will also include details of the SQL queries executed along with their execution time.

Fig. 12. Example of a report timeout in a diagnostic session, showing the SQL query and its execution time

The captured query can then be executed in SQL Server Management Studio to analyze its current execution plan—focusing on index usage and statistics freshness.

Further optimization may include removing or modifying calculated columns.

IIS

While working in the BPS Portal, the user's browser sends HTTP requests to the IIS server, which hosts the WEBCON BPS application. The server is responsible for processing these requests and returning responses to the client (the user’s browser). IIS has its own configurable timeout for handling individual requests, which is set to 120 seconds by default. If processing a request takes longer than this limit, the server responds with a “Bad Gateway” error, displayed in the user’s browser. Importantly, this error does not interrupt the SQL Server transaction if it was initiated by the IIS server. This means that even if the error message is shown to the user, the operation may continue in the background, and upon refreshing the view, the result of the successfully completed transaction may still be visible.

To illustrate this behavior, the following example was used: a path transition includes six Change value of single field actions, each taking 25 seconds to execute, with the automation timeout set to 240 seconds.

As explained in previous sections:

• all actions will complete successfully (the upper limit for SQL COMMAND is 30 seconds),
• the automation will take 150 seconds (6 actions × 25 seconds) and also finish without errors (within the 240-second limit).

Therefore, no internal application timeout will prevent the path transition. However, due to the 120-second limit configured in IIS, the user will still receive a “Bad Gateway” error.

Fig. 13. "Bad Gateway" error displayed to the user when the IIS request timeout is exceeded

In such cases, the Logger View will not contain additional information. This is a generic error generated by IIS.

Fig. 14. "Bad Gateway" in the Logger View

As mentioned earlier, the IIS timeout does not stop the SQL Server transaction. Once the transaction is complete and the workflow instance is refreshed, the path transition will appear as successfully completed after approximately 150 seconds.

In the instance History, a record will confirm that all operations were successfully executed.

Fig. 15. Successful instance update in History despite a browser timeout

While the “Bad Gateway” error can occur with any long-running request not terminated by the application itself, some commonly observed scenarios include:

• exporting a report to Excel,
• deleting a workflow/process in Designer Studio (even if the error occurs, the object continues to be deleted in the background transaction).

Summary

Execution timeouts are a valuable mechanism that help ensure smooth operation for both users and system services. They prevent long-running operations from blocking workflows or resources. Proper timeout management improves application responsiveness, accelerates queue processing (by aborting excessively long tasks), and makes it possible to handle more demanding operations (by increasing limits when necessary). Understanding and being aware of the various timeout types allows for more effective diagnostics and problem resolution.

Summary of timeout limits discussed in the article: