Decision tables

A Decision table evaluates conditions to determine an outcome. In its simplest form, it returns a single result based on the logic that best matches the input.

Depending on how the logic is designed, a Decision table can operate in two ways:

• Return the first matching result, where evaluation stops once a matching set of conditions is found.
• Evaluate all conditions and return multiple results, applying outcomes for every scenario that meets the defined criteria.

This flexibility allows a Decision table to either produce a single outcome or return multiple outcomes when conditions are not mutually exclusive, such as determining all applicable Rules, roles, or actions.

In addition to returning results, Decision tables can associate outcomes with related information. This allows the logic to not only determine what applies, but also define additional values or updates that should occur alongside the decision.

Decision tables are a good approach when you use a set of properties or Expressions to arrive at a Decision. For example, a banking application might determine a monthly maintenance fee by comparing account type and customer type. Each row evaluates a specific combination of values, and when a match is found, the table returns the corresponding fee. For instance, if the account type equals "Checking" and the customer type equals "Basic", then the system returns USD10.

The following example shows how the Decision evaluates based on account type and customer type property values:

By default, a Condition uses an equal comparison operator. When working with numeric Conditions, you can also use greater than, less than, or range-based comparisons. For example, you might define a Condition so that if a savings account balance is greater than USD1000, the customer is not charged any fees. You can also define ranges, such as charging a fee only when the balance falls between USD500 and USD1000.

Decision tables are commonly used to evaluate thresholds across multiple Conditions. For example, you can determine discount eligibility based on customer spending and tenure. Customers who purchase more than USD1000 in the previous year and have been with the company for five or more years might receive a 20 percent discount for purchases greater than USD50. Customers who meet the same spending criteria but have been customers for less than five years might receive a 15 percent discount on purchases greater than USD100. Customers who do not meet either Condition are not eligible for a discount.The following figure displays this Decision table:

You can set up calculated fields using out-of-the-box basic Functions and simple custom Expressions. For example, in an online grocery application, you can use an Expression to multiply the quantity by the unit price to calculate the total cost of an item.

For complex calculations which involve multiple Conditions with varying results based on the Conditions, you can set up a calculated field that references an existing or custom Decision table.

Consider the example of a YPlus cargo courier company that charges a USD500 delivery charge for courier services. YPlus has decided to update the delivery charge calculation based on distance. Suppose the delivery address is within 100 miles. In that case, the delivery charge is USD50. If the address is within 500 miles, the delivery charge is USD100. If the address is within 1000 miles, the delivery charge is USD250, and if the delivery address is farther than 1000 miles, the delivery charge is USD500. You set up a calculated field that references the Decision table described to determine the delivery charge.

Check your knowledge with the following interaction:

Organizations can delegate the maintenance of certain Rules to stakeholders who manage a specific Process within a Case Lifecycle. These stakeholders, sometimes referred to as Process owners, understand the business environment and can quickly identify changes that might impact how users achieve the desired outcome for a Case. You can delegate a Decision table to a Process owner, who can update the Decision logic to meet the changing needs. This approach is most helpful for small changes.

For example, a logistics manager might decide to set the order threshold for expedited shipping of customer orders to USD500 in the first release of an application. As business conditions change, to match a competitor, the logistics manager might want to lower the threshold to USD400. Rather than submitting a request for a developer to update the application and release a patch to apply to the production system, a Process owner can immediately update the threshold in production through delegation.

The sequence of Steps in a Case can vary based on the circumstances of that Case. Decision logic is used within a Process to evaluate conditions and determine how the flow should progress. For example, Decision tables can be used to guide what happens next in a Process or to determine how work should be directed. This allows the Process to adapt dynamically based on input data.

Automated next Steps

Decision-driven logic enables a Process to branch into different paths based on defined conditions. Instead of following a fixed sequence, the flow can adjust to different scenarios, making it more flexible and responsive.

Assignment routing

Decision logic can also determine who should perform work. By evaluating relevant information, the system can route an Assignment to the most appropriate individual, team, or queue. For example, work can be directed based on factors such as location, type of request, or priority, ensuring that it is handled by the most suitable resource.

Check your knowledge with the following interaction: