Description:

The HasDBRows step is a Database category workflow step that determines whether records are available from a SQL query.

The step requires a Connection string and SQL statement. You can supply an optional database name when the query needs to run against a different database. The step can also store the record count in a Variable/Global, specify a command timeout value, and use SQL parameters.

Usage:

The HasDBRows step is useful when a workflow needs to decide whether database records are available.

A typical pattern is:

Prepare SQL → HasDBRows → Process Records / Handle No Records

For example:

1. Select the database connection.
2. Enter the SQL statement that should be evaluated.
3. Optionally provide SQL parameters.
4. Optionally specify a Variable/Global for the record count.
5. Connect the True and False outputs to the appropriate workflow actions.

Enter the SQL statement through the multiline SQL input, and use optional SQL parameter mapping to supply parameter values.

Typical Workflow Suggestions:

Check Whether Pending Records Exist

Use HasDBRows before processing a queue or work table.

Example flow:

HasDBRows → True: Process Records → False: End/Wait

The SQL statement can check for records that are ready for processing. If records are available, the workflow continues into the processing path.

Determine Whether a Customer Record Exists

Use the step to determine whether a database lookup produced a record.

Example flow:

Receive Customer ID → HasDBRows → True: Continue → False: Handle Missing Customer

The SQL statement can use the customer identifier as a parameter. You can supply SQL parameters through the SQL parameters property.

Validate Prerequisite Data

A workflow can verify that required database information exists before continuing.

Example flow:

Collect Input → HasDBRows → True: Continue Processing → False: Validation/Exception Handling

This is useful when later workflow steps depend on information being present in the database.

Check for Unprocessed Transactions

Use HasDBRows as a gate before starting transaction processing.

Example flow:

HasDBRows → True: Process Transactions → False: Complete

The SQL statement can target transactions that meet the workflow's processing criteria.

Check for Outstanding Approvals

A workflow can query for outstanding approval records before initiating another action.

Example flow:

HasDBRows → True: Approval Exists → False: Continue to Next Stage

This allows the database state to influence workflow routing.

Determine Whether a Scheduled Job Has Work

For scheduled workflows, use the step to determine whether work is available.

Example flow:

Scheduled Start → HasDBRows → True: Execute Work → False: Finish

This pattern prevents downstream processing when the SQL query doesn't identify records requiring attention.

Store the Number of Records Found

When the workflow needs the record count later, configure Variable/Global to store it.

Example flow:

HasDBRows → Store/Use Record Count → Continue

The XML specifically identifies this property as the Variable/Global used to store the record count.

Use SQL Parameters for Dynamic Checks

Use the SQL parameters property when the SQL statement needs values supplied dynamically.

Example flow:

Set Variables → HasDBRows → True/False

This keeps values separate from the SQL statement and gives the step its defined SQL parameter-mapping capability.

Check Records in a Specific Database

Use Connect to different database when the workflow needs to execute the statement against a database other than the default database associated with the selected connection.

Example flow:

Select Connection → Specify Database → HasDBRows → Continue

The property is optional and is explicitly labeled Connect to different database in the step definition.

Control Long-Running Queries

For database operations where you need to control execution time, configure the command timeout value.

Example flow:

HasDBRows → True/False → Continue or Error Handling

The XML exposes this as an optional command-timeout property.

Example:

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

• Create a new process definition named “hasDBRowsDef” and open it in designer mode. 
• Drag a “hasDBRows” step to the canvas. 
• Define a variable or a global to store the result.
• Select the line between the steps to configure the “Connection Properties”. The default property values are “None, True, False, Error, and Evaluate”. Depending on the step’s purpose, you can configure additional values.
• Connect the dots between the “Start” step and “hasDBRows” steps, as shown above. 
• Click the “hasDBRows” step to configure its “Required” properties. Provide a name for the step. Select the connection string from the drop-down list. Enter a SQL SELECT query. 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 “hasDBRows” step to configure its “Optional” properties. If required, specify a different DB name (other than FlowWright); by default, the step connects to the FlowWright database. Specify a variable or global reference to store the result. Specify the time-out value (in seconds). Click the Save button. 

• The “Logging” configuration is necessary for documentation and for measuring workflow progress and the percentage complete. Configure the step state and percent fields individually, as shown in the images below. Configure the “Logging” using the following properties.

• Save the process definition, create a new instance, and execute it. Render the process instance and click the process step to view its properties. When the workflow reaches the Has Records? step, FlowWright performs the configured database operation using the supplied connection, SQL statement, and optional parameters. If configured, it stores the record count in the specified Variable or Global variable. The workflow then proceeds through the appropriate result path. Verify:
  • The correct database connection was used.
  • The SQL statement produced the expected result.
  • Any SQL parameters were supplied correctly.
  • The record-count Variable/Global contains the expected value when configured.
  • The expected True or False path was followed.

Tips:

• Use a SQL statement that directly represents the database condition the workflow needs to check.
• Select the appropriate Connection string before testing the workflow.
• Verify the database context when using Connect to a different database.
• Use SQL parameters for dynamic values rather than relying on hard-coded values where appropriate.
• Define a meaningful Variable or Global name when storing the record count.
• Configure a suitable command timeout for the database operation.
• Test the workflow with both scenarios: records available and records not available.
• Test SQL statements independently when troubleshooting unexpected results.
• Verify that SQL parameter names and values correspond to the SQL statement.
• Keep database queries focused so that the workflow performs only the database check it requires.
• Consider the expected query size and execution time when configuring the command timeout.
• Verify the stored record count before using it in downstream activities.
• Connect the False path to an appropriate alternate workflow action rather than leaving the outcome ambiguous.
• Use logging to make database-dependent workflow decisions easier to troubleshoot.
• Test the workflow against representative database data before deployment.
• Verify environment-specific connection settings after moving a workflow between environments.
• Do not assume specific SQL behavior, database-provider behavior, or parameter syntax beyond what is supported by the FlowWright implementation.
• Do not assume the exact runtime meaning of the True and False outputs for unusual SQL or database conditions solely from the XML definition; validate those cases in FlowWright.

Definition Sample:

You may download the sample definition from the link provided and later import it into the FlowWright Process Definition (XML file) or Form Definition (HTML file) page, following the same approach described in the reference documentation.

Note: Verify and complete any missing configuration after importing the sample, including:

• Connection string.
• SQL statement.
• Connect to a different database, if required.
• SQL parameters.
• Variable or Global variable used to store the record count.
• Command timeout value.
• Workflow Variable references.
• Environment-specific database settings.
• Downstream True and False workflow paths.

After verifying the configuration, save the Process Definition before execution.

Click here to download the sample file.