Configure a custom XPath calculation for Sort Property in Case Lists

How to Sort Cases Using a Calculated Property

1. Select the Case List

   • Within your project, select the desired Case List you want to sort.

   • Click on the Case List tab.

2. Create a New Calculated Sorting Property

   • Scroll to the Filtering and Sorting Section

   • Click the down arrow next to the Add Property button.

   • Select Sort Calculation from the dropdown menu.

   • Enter your XPath calculation in the property textbox.

   • Enter the column title in the Display Text textbox.

   • Choose the most appropriate format for your property.

     Open

     

For example, if you have a case property that represents risk, you may want to define custom logic to control how those risk values are ordered, rather than sorting them by their raw text values.

Case Property: risk

Values: Very Risky, Risky, Ok, Not too Risky, Safe

Instead of sorting by the face values, you could add the logic below:

if(risk = 'Very Risky', 1, if(risk ='Risky', 2, if(risk ='Ok', 3, if(risk ='Not too Risky', 4, 5))))

Open

Optimizing Custom XPath in Calculated Properties for Case List Sorting

However, every calculation has a performance cost; the more complex your XPath expression, the longer it may take to load your case list. This becomes especially important when mobile workers are handling multiple cases at once, have older devices, or devices with limited processing power.

Optimising your XPath for calculated properties keeps case lists fast and responsive, while still providing the flexibility to order cases exactly as you want.

XPath Performance Considerations

Sorting adds computational overhead, and poorly designed XPath expressions can slow down case list loading.

Why it matters:

• Every calculated property adds processing time each time the case list loads.

• If your app includes complex expressions (like nested if()s or case lookups), they can make scrolling sluggish or delay screen loads.

• The performance impact increases as your case list grows, especially when filters or searches are also applied.

Best practices for performance :

1. Use Indexed Case Properties Whenever Possible

Indexed properties are optimized for quick lookups. Always place indexed filters first and enclose them in their own brackets. Common indexed properties include:

• @case_type

• @status

• @case_id

• @owner_id

• @external_id

• index/INDEX_NAME

2. Order Predicates from Fastest to Slowest

• Place cheap, indexed filters first.

• Place complex, calculated filters later.

• Example: Suppose you want to list all TB patients whose age is over 18

• Indexed properties (@case_type) and simple filters (diagnosis = "tb") come first.

• More complex or calculation-heavy filters (age > 18) come later.

3. Avoid Nested Expressions

If your app includes complex expressions (like nested if()s or case lookups), they can make scrolling sluggish or delay screen loads.

4. Prefer Static Over Dynamic Variables

Static references (e.g., user data, case properties) are faster than dynamic values that update with form changes.

5. Number of calculated properties for case list

When designing your app, minimize calculated properties in the case list by performing calculations within the form and saving the result as a case property.

XPath examples for Sorting

1. Priority Sorting (Categorical Values)

2. Boolean Sorting (Yes/No)

3. Numeric Range Bucketing