Description:

The DB Decision Table step enables a FlowWright workflow to execute business decisions using configurable database tables instead of embedding business logic directly within the workflow.

A decision table provides a centralized location where business users or administrators can maintain decision rules without modifying workflow definitions. During execution, the workflow supplies one or more input values, searches the specified decision table for a matching record, and retrieves the configured output values.

If a matching row is found, the workflow follows the Matched path and populates the configured output variables. If no matching record exists, the workflow follows the NoMatch path. Optional default output values can also be configured to ensure downstream processing continues with predictable values when no matching rule is available.

Typical uses include:

• Approval routing
• Pricing decisions
• Discount calculations
• Department assignment
• Risk classification
• Customer categorization
• Geographic routing
• Business policy management

By externalizing business rules into database tables, organizations can simplify workflow maintenance while allowing business rules to evolve independently of workflow design.

Usage:

The DB Decision Table step is typically used whenever business decisions should be maintained outside the workflow definition.

During execution:

1. Read the configured decision table name.
2. Collect the mapped input values.
3. Search the database decision table for a matching record.
4. If a match is found, populate the configured output variables.
5. If no match exists, optionally assign the configured default values.
6. Continue workflow execution through either the Matched or NoMatch return path.

A typical workflow might look like this:

Typical workflow scenarios include:

• Determining approval levels
• Assigning service representatives
• Selecting shipping methods
• Calculating pricing tiers
• Mapping product categories
• Routing support requests
• Determining regional processing rules

Example:

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

• Create a new process definition called “evalDBDecisionTableDef” and open it in the designer mode. 
• Drag an “UpdateVariable, evalDBDecisionTable” step to the canvas. 
• Connect the dots between the “Start” and other steps, as shown above.
• Define a variable or a global to store the result.
• Click the "UpdateVariable" step to configure its "Required" properties. Enter a step name. 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 "UpdateVariable" step to configure its "Optional" properties. Enter a variable reference and the value to store. Select “Yes” if the value is an expression to evaluate. Click the Save button. 

• Click the "evalDBDecisionTable" step to configure its "Optional" properties. Provide a name for the step and a table name for the decision evaluation. Click the button to map the DB input and output columns, then click Save. Note: Click the "AI Predict" button for the Copilot to add new process steps that match your process description. 

• Click the button to map the DB Input columns. Click the Add Row (+) button to insert an empty row. Provide the input DB column and the variable/global reference to be mapped. Select the Contains checkbox if the value is a string to be searched within another string. Click the Save button. You may use the Add Row button to insert multiple DB input columns and variable references. Click the Save button. 

• Click the button to map the DB output columns. Click the Add Row (+) button to insert an empty row. Enter the output DB column and the variable or global reference to map. Click the Save button to confirm. You may use the Add Row button to insert multiple DB output columns and variable references. Click the Save button. 

• Click the "evalDBDecisionTable" step to configure its "Optional" properties. Click the button to map the DB output columns. Click the Add Row (+) button to insert an empty row. Provide the output DB column and the variable or global reference to map for no match. Click the Save button to confirm. You may use the Add Row button to insert multiple DB output columns and variable references. Click the Save button. 

• The “Logging” configuration is necessary for documentation and also measures workflow progress and percent complete. This is achieved 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 instance, and execute it. Render the process instance. Click the process step to view its properties. The process should use the DB decision table. Below, the step properties show the values for an evaluated match.  

Tips:

• Design decision tables so that each combination of input values produces a single, unambiguous result.
• Use descriptive table names that clearly identify the business purpose.
• Keep business rules within the database instead of embedding them in workflow logic whenever frequent rule changes are expected.
• Configure default values to provide predictable behavior when no matching record exists.
• Route the NoMatch path to logging or administrative review to identify missing business rules.
• Regularly review and update decision tables as business policies evolve.
• Combine this step with Evaluates Multiple Expressions, Decision, Business Rule, Update Variable Values, Send Email, or Create Process Instance steps to build flexible, rule-driven workflows.

Notes:

• A valid decision table name is required before the step can execute.
• Input and output column mappings should correspond to the structure of the configured database decision table.
• Default values are optional and are applied only when no matching record is found.
• The Matched and NoMatch return paths should both be implemented to provide complete workflow handling.
• Business rules can be modified by updating the decision table without changing the workflow definition.
• Execution details and decision evaluation results are recorded in the FlowWright workflow execution log.

DB Decision Table vs. Evaluates Multiple Expressions:

Both workflow steps evaluate business logic, but they are designed for different decision-making approaches.

As a general guideline:

• Use DB Decision Table when business rules should be maintained centrally in a database and updated without modifying workflows.
• Use Evaluates Multiple Expressions when workflow-specific validation or logical expressions are sufficient and database-driven rule management is not required.

Definition Sample:

You may download the sample workflow definition from the link provided and import it into your FlowWright environment.

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

• Decision table name
• Input column mappings
• Output column mappings
• Default values (if required)
• Success and alternate workflow branches
• Database access permissions

After verifying the configuration, save and publish the workflow before execution.

Click here to download the sample file.