MAF Configuration Practices – Combine static and dynamic filters

Overview

This is a configuration to apply static and dynamic filters that can work for connected and disconnected. This is an important use case because some combinations might not work as expected, for instance, declared filter in XML can be overwritten by the filter injected through API.

Use Cases:

Static filter already defined in datasource XML where dynamic portion needs to be introduced
Address both static and dynamic values to datasource filter

Prerequisites:

Basic understanding of datasources

Implementation

Step 1: Create a section in AppCustomization.js to address filter for that specific datasource during initialization

onDatasourceInitialized(datasource, app) {
    if (datasource.name === 'mydatasource') {

    }
}

Step 2: Compute and store the dynamic value in a variable or state

onDatasourceInitialized(datasource, app) {
    if (datasource.name === 'mydatasource') {
      let orgid = app.client.userInfo.defaultOrg;
    }
}

Step 3: Use updateBaseQuery to set both qbe and mobile filters

onDatasourceInitialized(datasource, app) {
    if (datasource.name === 'mydatasource') {
      let orgid = app.client.userInfo.defaultOrg;

      datasource.updateBaseQuery({
        "mobileQbeFilter": {
          "orgid": orgid,
        },
        "qbe": {

Step 4: Check for existing filter defined in that particular datasource

<maximo-datasource id="mydatasource" mobile-qbe-filter="{{'WORKTYPE': '!=*'}}" where="WORKTYPE!=&quot;*&quot;" [...]>
  <!-- [...] -->
</maximo-datasource>

Important Notes:

It is important to keep all filters in a single format to avoid unexpected behavior caused by build or runtime

Step 5: Move defined filters in XML along with filters defined in datasource API.

<maximo-datasource id="mydatasource" [...]>
  <!-- [...] -->
</maximo-datasource>

onDatasourceInitialized(datasource, app) {
    if (datasource.name === 'mydatasource') {
      let orgid = app.client.userInfo.defaultOrg;

      datasource.updateBaseQuery({
        "mobileQbeFilter": {
          "orgid": orgid,
          "worktype": "null"
        },

Validation & Testing

How to verify the configuration works:

Test Step 1: Build and deploy the application with the updated AppCustomization.js
- Expected Result: Application builds successfully without errors
Test Step 2: Open the page containing the datasource and check browser console or device logs
- Expected Result: Datasource loads with both static and dynamic filters applied correctly
Test Step 3: Verify the filtered data in both connected and disconnected modes
- Expected Result: Data is filtered according to both the static filter (e.g., WORKTYPE!=*) and dynamic filter (e.g., orgid matches user’s default organization)

Common Issues:

Issue: Dynamic filter overwrites the static filter defined in XML
- Cause: Using setQBE or other filter methods that replace the entire filter instead of merging
- Solution: Use updateBaseQuery with both mobileQbeFilter and qbe properties to merge filters properly
Issue: Filters work in connected mode but not in disconnected mode
- Cause: Only setting qbe without mobileQbeFilter, or vice versa
- Solution: Always set both mobileQbeFilter and qbe in updateBaseQuery to ensure consistency across modes

Best Practices

✅ Do:

Always use updateBaseQuery to merge filters instead of replacing them
Set both mobileQbeFilter and qbe properties to ensure consistency across connected and disconnected modes
Keep all filters in a single consistent format (either all in XML or all in code) to avoid conflicts
Initialize filters in onDatasourceInitialized to ensure they’re applied before data loads

❌ Don’t:

Don’t mix filter definitions between XML and code without proper merging strategy
Don’t use setQBE directly as it will overwrite existing filters
Don’t forget to handle null or undefined values in dynamic filters
Don’t apply filters after datasource has already loaded data

Performance Considerations:

Apply filters during datasource initialization to avoid unnecessary data fetching
Use specific field filters rather than broad queries to reduce server load
Consider the impact of complex filters on mobile device performance in disconnected mode

Prerequisites:

Datasources Guide - Understanding datasource fundamentals
Concepts - Core MAF concepts

Related Practices:

Dynamic Mobile Filter - Alternative approach for dynamic filtering
Modify Default Queries - Simpler query modification techniques
Client-Side Datasource Filtering - Filtering data after load

External Documentation:

Additional Notes

Mobile Considerations:

mobileQbeFilter is specifically for disconnected/mobile mode filtering
Both qbe and mobileQbeFilter should be set to ensure consistent behavior
Mobile filters are applied locally on the device in disconnected mode
Test thoroughly in both connected and disconnected modes

Advanced Tips:

You can use complex filter expressions with operators like !=, >, <, etc.
Filters can reference multiple fields in the same updateBaseQuery call
Consider using null checks when dealing with optional dynamic values
For performance, apply the most restrictive filters first

Troubleshooting:

Enable debug logging in the browser console to see filter application
Check the network tab to verify the WHERE clause in API requests
Use the Debug UI feature to inspect datasource state and filters
Verify filter syntax matches the expected format for both qbe and mobileQbeFilter

Edit this page on GitHub

Page last updated: 19 January 2026

Complex configurations: Dynamic Mobile QBE Filter

Complex configurations: Add custom query to Service Request app

Combine static and dynamic filters