Avoid Delegation Warnings When Using If() Inside Filter() in Power Apps

I recently came across a delegation warning caused by the following formula:

Filter(
    dataSource,
    If(
        !IsBlank(DatePicker.SelectedDate),
        Created <= Today() - 15,
        Created <= DatePicker.SelectedDate
    )
)

Even though the individual comparisons are delegable, placing an If() function inside Filter() can cause Power Apps to treat the entire expression as non-delegable. This may lead to incomplete or inaccurate results when working with large data sources.

Why Does This Happen?

Power Apps delegation allows queries to be processed directly by the data source instead of locally within the app. When a non-delegable function is introduced into a Filter() predicate, Power Apps may be unable to translate the query into a format that the data source can execute efficiently.

In this example, the use of If() inside Filter() prevents Power Apps from fully delegating the query.

Better Approach 1: Move the `If()` Outside the `Filter()`

Instead of placing the conditional logic inside the filter predicate, move the decision-making outside and apply separate Filter() statements.

If(
    !IsBlank(DatePicker.SelectedDate),
    Filter(dataSource, Created <= Today() - 15),
    Filter(dataSource, Created <= DatePicker.SelectedDate)
)

Why This Works

Each branch contains a simple Filter() expression.
The filter condition remains straightforward and delegable.
Power Apps can translate each query more effectively for supported data sources.

Better Approach 2: Precompute the Value and Then Filter

Another clean approach is to calculate the date value first and store it in a variable.

Set(
    varCutoffDate,
    If(
        !IsBlank(DatePicker.SelectedDate),
        Today() - 15,
        DatePicker.SelectedDate
    )
);

Filter(
    dataSource,
    Created <= varCutoffDate
)

Why This Works

The If() function executes once outside the query.
The Filter() predicate remains a simple comparison.
The variable can be reused elsewhere in the application.
The formula is easier to read and maintain.

When Should You Use This Pattern?

This approach is particularly useful when:

Working with large SharePoint lists.
Querying Dataverse tables.
Using SQL Server or other delegable data sources.
Reusing the calculated value across multiple controls or screens.

In many cases, the variable-based approach is the most maintainable solution because it separates business logic from data filtering logic.

Key Takeaways

❌ Avoid using If() (or other non-delegable functions) directly inside Filter().
✅ Keep the Filter() predicate as a simple, delegable comparison.
✅ Move conditional logic outside Filter() whenever possible.
✅ Use an outer If() or a precomputed variable to maintain delegation.
✅ Verify delegation behavior when working with large datasets.

Summary

A common cause of delegation warnings in Power Apps is placing conditional logic such as If() directly inside a Filter() function. Although the individual comparisons may be delegable, the combined expression often is not. By moving the decision-making outside the filter or precomputing values in a variable, you can keep your queries delegable, improve performance, and ensure accurate results when working with large data sources.

Why Does This Happen?

Better Approach 1: Move the If() Outside the Filter()

Why This Works

Better Approach 2: Precompute the Value and Then Filter

Why This Works

When Should You Use This Pattern?

Key Takeaways

Summary

Better Approach 1: Move the `If()` Outside the `Filter()`