What Is a Date Picker in Paginated Reports?
A date picker is the user-friendly pop-up calendar that lets report consumers select a date or date range — the kind of experience Power BI Desktop makes trivially easy with a date slicer. In paginated reports, getting to the same result takes a few more deliberate steps.
When you go into the query designer to add a date parameter, you start by defining the date table and the date field, then choose Range Inclusive as the operator so the report captures both the start and end dates the user selects. Make sure to click the parameter boxes for both the start and end dates — if you only check one, the other will default to a static filter instead of a user-driven parameter.
Why It Fails After You Validate
After validating the query and clicking OK, you'd be forgiven for thinking you're done. But when you test the report, it fails — and the error usually isn't obvious.
Here's what's actually happening behind the scenes: Power BI Report Builder sets up a parameter relay race. It creates "from" and "to" date parameters and sets their data type to DateTime, which is the correct type for a date picker UI. But it also auto-generates a hidden dataset that connects to those parameters and populates the available values list.
The Fix: Four Changes to Make
The solution requires four coordinated changes. Each one matters — skipping any of them tends to bring the problem back.
Open the Report Parameter Properties for both your "from" and "to" parameters. Under General, confirm the data type is set to Date/Time. If it got set to Text at any point, the date picker UI won't render.
In the Report Data pane, expand the Datasets folder. You'll see one or two auto-generated datasets with names like DataSet1 or similar — these were created by Report Builder to drive the available values. Delete them. They're the source of the type conflict, and your parameters don't need available values to function as a date picker.
In the Report Parameter Properties, go to the Default Values tab and set useful defaults so the report doesn't require the user to pick dates before it will render at all.
For the "from" date, use the expression: =DateAdd("d", -365, Today())
For the "to" date, use: =Today()
This is the counterintuitive part. Your DAX query needs date strings in yyyy-MM-dd format, not DateTime values. So in the dataset query that powers your report, use a format expression to convert the DateTime parameter into the string the query expects:
=Format(Parameters!StartDate.Value, "yyyy-MM-dd")
This lets the parameter UI remain DateTime (so the calendar picker works) while passing a correctly formatted string into the underlying DAX query.
What You End Up With
After these four changes, you'll have a functional date picker that defaults to the past year through today, renders a calendar when the user clicks the parameter field, and correctly filters the report data without type-mismatch errors.
DateAdd and Today() → use Format() in the dataset query to convert back to the string the DAX needs.
The mismatch between what the UI needs (DateTime) and what the DAX query needs (formatted string) is what trips up most developers. Once you understand that, the fix is straightforward — you're just bridging the two with a format expression.
Related Topics
If you're finding paginated report parameter management in general to be rough going, some common follow-on issues worth investigating: cascading parameters that fire in the wrong order, multi-value parameters with DAX IN filters, and report subscriptions that don't respect default parameter values. All of these have workable solutions — the core principle is the same: understand what each layer of the stack expects and build explicit bridges between them.