Description:

The Execute SQL Statement step belongs to the Database category in FlowWright. Its XML definition identifies the step as executesql, with the label “Executes a SQL statement” and display name “Execute SQL Statement.”

The step connects to a configured database and executes the SQL statement supplied in the SQL statement property. It can optionally store the resulting value in a workflow variable or global variable. The step also provides options for result formatting, returning a single result, command timeout, SQL parameters, changing the database, and using a transaction.

Typical uses include:

• Retrieving information from a database
• Inserting, updating, or deleting database records
• Executing parameterized SQL statements
• Returning database results to workflow variables
• Executing SQL against a different database
• Performing database operations within a transaction
• Applying database-driven business rules
• Updating workflow-related database information
• Integrating external database operations into business workflows

This step provides True and False execution paths so the workflow can branch based on whether the SQL operation succeeds or fails.

Usage:

The Execute SQL Statement step is typically placed in a workflow when business-process execution needs to interact directly with a database.

During execution:

1. Select the required Connection string.
2. Optionally specify a connection to a different database.
3. Enter the required SQL statement.
4. Optionally configure SQL parameters.
5. Configure the desired Result format.
6. Optionally specify a result variable/global.
7. Configure timeout or transaction behavior when required.
8. Execute the step.
9. Continue workflow processing through the True or False path.

A typical workflow might look like:

Example:

Let’s build and execute the “executeSQLDef” example.                             

• Create a new process definition named “executeSQLDef” and open it in designer mode. 
• Drag a few “executeSQL” steps to the canvas.
• Connect the dots between the “Start” and the “executeSQL” steps, as shown above.
• Define a variable or a global variable to store the result.
• Click the first "executeSQL" step to configure its "Required" properties. Provide a name for the step. Select the connection string from the list. Enter the SQL SELECT statement. In this example, the statement includes a parameter (?), and the value is supplied via a variable reference. Select the result format as XML or JSON. Click the Save button. Note: Click the "AI Predict" button to have Copilot add new process steps that match your process description. 

• Click the first "executeSQL" step to configure its "Optional" properties. Provide a variable or a global to store the result. Select the result to return a single row or column (if necessary). Set the SQL command timeout value in seconds. Click the button to configure the SQL parameters and values. A pop-up window appears for configuration. Click the Add Row button to insert an empty row. Provide the SQL parameter and value. Click the Save button. Use the Add Row button to include multiple SQL parameters and values. Select “No” for the Use Transaction property. 

• Click the second "executeSQL" step to configure its "Required" properties. Enter a name for the step. Select the connection string from the list. Enter the SQL SELECT statement. In this example, an attempt is made to set the primary constraint field [dePrimaryKey] to an invalid value to generate a transaction error. Choose the result format as XML or JSON. Click the Save button. Note: Click the "AI Predict" button to have the Copilot add new process steps that match your process description. 

• Click the second "executeSQL" step to configure its "Optional" properties. Provide the DB name if you prefer a different database. Leaving it blank connects to the database specified in the connection string. Provide a variable or global reference to store the result. Select the result to return a single row or column (if necessary). Set the SQL command timeout value in seconds. Click the button to configure the SQL parameters and values. Select “Yes” for the Use Transaction property; this allows the SQL operation to be configured for use with transactions. Click the Save button. Note: Transactions can be useful for database operations where the SQL changes should be treated as a transactional unit. The transaction is committed only when the SQL changes are successful without errors.   

• Click the last "executeSQL" step to configure its "Required" properties. Provide a name for the step. Select the connection string from the list. Enter the SQL SELECT statement. In this example, the statement executes a stored procedure, and the parameter values (?) are supplied via a variable reference. Select the result format as XML or JSON. Click the Save button. Note: Click the "AI Predict" button to have Copilot add new process steps that match your process description. 

• Click the last "executeSQL" step to configure its "Optional" properties. Provide a variable or global reference to store the result. Select the result to return a single row or column (if necessary). Set the SQL command timeout value in seconds. Click the button to configure SQL parameters and values. A pop-up window opens for configuration. Click the Add Row button to insert an empty row. Enter the SQL parameter and value. Click the Save button. Use the Add Row button to add multiple SQL parameters and values. 

• The “Logging” configuration is necessary for documentation and to measure workflow progress and percent complete. This is done by configuring the step state and percent fields individually, as shown below. Configure the “Logging” using the following properties.

• Save the process definition, create a new process instance, and execute it. Render the process instance. Click the process step. The step should execute the SQL query on the selected database server and return the result in the format specified in the result configuration (JSON or XML). Note: The transaction error follows a different workflow path, as configured in this example. 

• To connect to a different database, specify the database name using the exact connection string. 

Tips:

• Always configure the required Connection string and SQL statement properties. 
• Use SQL parameters instead of constructing SQL by concatenating workflow values where parameterization is appropriate.
• Configure the result format according to the requirements of the consuming workflow step.
• Use Variable/Global to store the value when subsequent workflow processing needs the SQL result.
• Use Return a single result when the workflow specifically expects one result.
• Configure Command timeout value appropriately for long-running operations.
• Use Use transaction when transactional behavior is required and supported by the database operation.
• Use the False path to handle SQL execution failures.
• Avoid unnecessarily complex SQL in workflows when a reusable database operation would provide better maintainability.
• Test SQL statements independently before deploying the workflow.

Notes:

• ExecuteSQL is a Database workflow step. 
• Its display name is Execute SQL Statement. 
• It has 2 input connections and 2 output connections. 
• Connection string is required. 
• SQL statement is required. 
• Result format is required and defaults to XML. 
• Variable/Global to store the value is optional. 
• SQL parameters are optional. 
• Use transaction is optional. 
• True and False execution paths are available. 
• The XML does not document the complete runtime result schema, supported result-format values, transaction semantics, or timeout units. These should not be inferred from the XML alone.

ExecuteSQL vs. ExecuteJob:

Both ExecuteSQL and ExecuteJob belong to the Database category, but they operate at different levels.

ExecuteSQL directly executes a SQL statement.

ExecuteJob executes a named job.

The ExecuteJob XML defines only two configurable properties: Connection string and Variable/Global to enter the job name.

When to use ExecuteSQL

Use ExecuteSQL when the workflow needs direct control over the database operation.

Examples:

• Query database information
• Insert records
• Update records
• Delete records
• Execute parameterized SQL
• Retrieve database results
• Use a transaction
• Configure command timeout
• Return results to workflow variables

When to use ExecuteJob

Use ExecuteJob when the database operation is encapsulated as a predefined job, and the workflow only needs to invoke that job.

Examples:

• Trigger a predefined database job
• Reuse an existing database operation
• Keep database processing encapsulated outside the workflow
• Invoke standardized database processing from multiple workflows

Key distinction

ExecuteSQL: “Execute this SQL statement against the database.”

ExecuteJob: “Execute this named database job.”

In short:

• Use ExecuteSQL for direct, configurable SQL execution.
• Use ExecuteJob for invoking an existing database job.
• Use ExecuteSQL when the workflow needs SQL parameters, result handling, timeout control, or transaction configuration.
• Use ExecuteJob when the database operation is already encapsulated in a job and the workflow only needs to trigger it.

Both provide True and False execution paths, allowing either step to participate in conditional workflow processing.

Definition Sample:

You may download the sample definition(s) from the provided link and later import them (drag-and-drop) into your FlowWright Process Definition (XML file) or Form Definition (HTML file) page. 

Note: Please verify and complete the process steps for any missing configurations, such as file path references and database connections, after the import. Then, save the definition to confirm the changes. 

Click here to download the sample file.