What is a Parameter ?
Alpana v2.0 introduced the concept of Parameters : a proxy between actions and results in a Dashboard.
A Parameter takes 0 or more values.
What is this for ?
Dashboard Widgets can be bound to listen to Parameters : when the Parameter changes, the Widget becomes filtered to only show corresponding values.
Custom Queries can also be parametrized by Parameters : when the Parameter changes, the Custom Query is updated in consequence.
Parameters can be bound to listen to one or more Master Widgets to update their values.
Parameters values can also be set through Dashboard or Widget URLs to change their default value.
You can open the Parameters Editor using the
Dashboard>Edit Filters... menu or
Ctrl+Shift+F keyboard shortcut.
From there, you can manage Parameters :
- create Parameters
- rename Parameters
- remove Parameters
- change default value
- change bindings between Widgets and Parameters
With Filter Widgets
Parameters are automatically created on Filter creation to serve as a proxy between a Master Widget and its Listener Widgets.
By default, all possible Listener Widgets in the Dashboard that are configured with the same field as the Filter Widget will be bound as Listener to this Parameter.
You can bind Parameters to any Listener Widget independently of its Data Source and independently of the corresponding field name.
This can be useful if you want to use for example a single date filter to apply to several Listener Widgets from different Data Sources. You will have consistant filtering and avoid duplication.
To achieve this, the Master Widget must be able to send the required values to the Parameter.
Multi-DataSource filtering : Example scenario 1
For example if DataSource1 has fewer values than DataSource2 (maybe a narrower date range, maybe not all equipments appear in this equipment list), then using the field from DataSource1 in the Master Widget will render you unable to send those missing values to the Parameter.
To solve this, you can use the field from DataSource2 which contains the most values (the widest date range, or the complete equipment list).
Note however that in this case you will try to filter Widgets from DataSource1 which may not contain the values and will return empty results.
Multi-DataSource filtering : Example scenario 2
If DataSource1 has some values that are not in DataSource2, and the other way around, then you cannot list all possible values in a Filter Widget by binding a field from one of your existing Data Source directly.
To solve this, you can create an additional Data Source dedicated to contain all the filter values you need to use. It could be a Custom Query with an
UNION of both data sets, or it could come from one of your reference tables listing all equipments for example.
Note once again that when you will filter for values that exist only in one of the Data Sources, the Widgets bound to the other Data Source will return empty results.
With Stored Procedures or Table-Valued Functions
Parameters can be used as arguments to Stored Procedures or Table-Valued Functions : when the Parameter changes, the Stored Procedure or Table-Valued Function is called again with the new values as arguments.
With Custom Queries
Parameters can be used inside Custom Queries : when the Parameter changes, the Custom Query is called again with the new values for the Parameter.
With URL Parameters
The default value of any Parameter can be set from a URL Parameter.
This means that a particular set of filters can be used when opening the dashboard if the correct URL Parameters are configured.
You dashboard contains a Parameter called Parameter1 and another called Parameter2 which accepts multiple values. The dashboard is published at
You can browse your dashboard with :
It will give a default value for your Parameters :
Parameter1takes single value
Parameter2takes multiple values
The following names are reserved and cannot be used as URL Parameters. Please rename the corresponding Parameters.