---
schema_version: "1"
id: e8da2f22eab0f108efff568a56daac6ceb56a794a8cc6995e26aef3a61507ce5
title: Best Practices for Standard Decision Tables
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/ind/264-0-0/bre_best_practises_lowvolume_dt.md
canonical_url: https://help.salesforce.com/s/articleView?id=ind.bre_best_practises_lowvolume_dt.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: b27cca73a24dd9399155ab28434f1c3c45ccc3c4533981a036ec833c2f4728c6
description: Follow the best practices for optimizing your standard decision tables for performance and scalability.
products:
  - Industry Solutions
  - Cross Cloud
release: "264"
---
# Best Practices for Standard Decision Tables

Follow the best practices for optimizing your standard decision tables for performance and scalability.

### Required Editions

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small edition"><colgroup><col></colgroup><tbody><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: Lightning Experience</td></tr><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: <strong>Enterprise</strong>, <strong>Unlimited</strong>, and <strong>Developer</strong> Editions for clouds that have Business Rules Engine enabled</td></tr></tbody></table>

Best Practices for Optimal Performance

- If you have a decision table with a large volume of rows, consider partitioning the decision table for better performance. Make sure that each partition has a unique partition key and the partition size doesn’t exceed 25,000 rows.
- When you create a standard decision table, if you have mandatory conditions that use the Equals operator, and the condition type is set to Custom, make sure that these conditions are grouped together in the Effective Logic field. Group these conditions to minimize the lookup complexity and improve the rule evaluation efficiency.
    
    Consider this example where five conditions are created and the condition type is set to Custom when you create a standard decision table.
    
        
    | condition | source object field | operator | cOLUMN NAME | Optional? |
    | --- | --- | --- | --- | --- |
    | 1 | BillingCity | Equals | BillingCity | No |
    | 2 | BillingState | Equals | BillingState | No |
    | 3 | Industry | Equals | Industry | No |
    | 4 | Type | Equals | Type | No |
    | 5 | OwnerId | Equals | OwnerId | No |
    
    For this scenario, the correct effective logic is `(1 AND 2 AND 3) AND (4 OR 5)`.
- Condition sequence affects the lookup performance. Place the condition that filters out the most rows early in the condition logic to minimize unnecessary evaluations. Identify the columns that filter out the most records early. Prioritize columns that have unique or highly varying values over those with repetitive values.
    
    For example, when you set BillingCity as the column in the first condition, more table lookups are required because a significant number of rows are not reduced early. However, when you place Industry as the column in the first condition, irrelevant records are filtered out early making subsequent conditions more efficient.
- When you define conditions with input fields such as City or Property that have multiple eligible values, use separate rows for each value with the Equals operator instead of combining values into a single row with a partial match.
    
    For example, if the input field is City and the eligible values are New York, London, and Mumbai, create three separate conditions, each using the Equals operator as shown in this table:
    
        
    | condition | source object field | operator | cOLUMN NAME | Optional? |
    | --- | --- | --- | --- | --- |
    | 1 | City | Equals | NewYork | No |
    | 2 | City | Equals | London | No |
    | 3 | City | Equals | Mumbai | No |
- Ensure that you provide an input to a Required field that uses the Equals operator to avoid errors.

Best Practices for Optimal Scalability

If you have a decision table with a large volume of rows, consider partitioning the decision table. Make sure that each partition has a unique partition key and the partition size doesn’t exceed 25,000 rows.