What Are Report Parameters?

Parameters are user inputs that control what data your report displays. Instead of a static report that always shows the same data, a parameterized report asks the user to provide inputs when running it. These inputs filter the data shown in the report.

For example, a general ledger report could ask “Which date range would you like to see?” When the user runs the report, they specify a date range, and the report shows only transactions within that range. Another GL report might ask “Which cost center?” allowing users to see financial data for a specific cost center.

Parameters make your reports flexible and reusable. Instead of creating separate reports for each cost center, you create one report with a cost center parameter and users select their cost center when running the report.

Creating a Simple Date Range Parameter

The most common report parameter is a date range. Users typically want to run the same report for different time periods—this month, last quarter, year-to-date, etc.

To add a date range parameter to your report, open your report in the designer and navigate to the Parameters section (usually a panel on the left side of the designer). Click “Add Parameter.” A dialog appears asking you to define the parameter:

Parameter Name: This is the internal name of the parameter. Use something descriptive like “StartDate.” Display Name: This is the user-friendly label that appears when someone runs the report. “Start Date” (with a space) is clearer than “StartDate.” Data Type: Select “Date” from the dropdown. Default Value: Optionally set a default, like “first day of current month.” This saves users from having to specify a value if they want the default behavior.

Create a second parameter for the end date using the same process. Now you have two parameters: StartDate and EndDate.

Using Parameters to Filter Data

Creating a parameter isn’t enough—you need to connect it to your report’s data. When you add a date range parameter, you need to tell your report “filter transactions to only show those between the StartDate and EndDate.”

This is done through filters, which are conditions applied to your report’s data. In the report designer, look for a “Filters” section. Click “Add Filter” and create a condition like:

“Transaction Date” is greater than or equal to [StartDate] AND “Transaction Date” is less than or equal to [EndDate].

The bracket notation [StartDate] tells the report to use the parameter value instead of a literal date. When someone runs the report and specifies a date range, the filter automatically applies that range to the data.

Creating Selection List Parameters

Besides dates, another common parameter type is a selection list. Instead of asking users to type a value, you present them with a dropdown list of valid options.

For example, a cost center parameter might have a dropdown listing all cost centers in your company. Users select one from the list rather than typing a cost center ID. This prevents typos and ensures users only select valid cost centers.

To create a selection list parameter, define the parameter with Data Type = “List.” Then specify the list source—either a fixed list of values you hardcode (“Cost Center A,” “Cost Center B,” “Cost Center C”) or a dynamic list pulled from your database (a query that returns all active cost centers).

Dynamic lists are better than hardcoded lists because they automatically update as new cost centers are added to your system. If you hardcode the list and someone creates a new cost center, users won’t see it in the parameter dropdown until you manually edit the report.

Cascading Parameters

Advanced parameter scenarios involve cascading parameters, where the options available in one parameter depend on the selection in another parameter. A classic example: a country parameter followed by a state/province parameter. After the user selects “United States,” the state parameter only shows US states. If they select “Canada,” the state parameter shows Canadian provinces.

Cascading parameters require more sophisticated setup. The second parameter’s value list is a query that takes the first parameter’s selected value as input. This requires some SQL knowledge or help from an experienced report developer, but the result is a much better user experience because users aren’t overwhelmed with a huge list of all possible values.

Optional vs. Required Parameters

When you define a parameter, you can mark it as required or optional. A required parameter must be provided before the report can run. An optional parameter can be left blank, and the report runs with a default behavior when it’s not specified.

For most parameters, make them required. This forces users to consciously select values, reducing the chance that they’ll run the report by accident without specifying the filters they intend.

Optional parameters are useful when you want to give users a choice: if they fill in a specific filter, the report applies it; if they leave it blank, the report shows all data. This makes one report serve multiple use cases.

Using Parameters in Report Logic

Parameters aren’t just for filtering data. You can use them to control report appearance and behavior. For instance, you might show or hide entire report sections based on a parameter value. A “Detail Level” parameter might control whether the report shows transaction-level detail or only summary totals.

You can also use parameters in calculated fields and formulas. For example, a “Show Variance” parameter might control whether your report calculates and displays budget vs. actual variances.

This kind of conditional logic makes your reports adapt to different users’ needs without requiring separate reports for each scenario.

Parameter Best Practices

Use clear, descriptive display names. Don’t call a parameter “CostCenter”—call it “Select Cost Center.” Users understand immediately what they’re being asked to do.

Provide sensible defaults when possible. A report that defaults to “last 30 days” saves users from having to select the date range every time they run it.

Order parameters logically. If you have cascading parameters, put the parent parameter first. Group related parameters together.

Validate parameter input when possible. If you have a numeric parameter, restrict it to positive numbers. If you have a date parameter, ensure the end date is after the start date. This prevents users from accidentally running reports with invalid parameters.

Document your parameters. If you build a report with complex parameters, add notes explaining what each parameter does and what values are valid. This helps other users understand how to use the report effectively.