Overview
Filters can be used to display subsets of data in an application. For instance, imagine a retrieval built over a sales history table with over 100,000 records. It is not always practical to show all 100,000 records at one time. Perhaps an end-user needs to be able to select a particular date range, or the data needs to be secured so that employees in different departments can only access specific sales records. Filters make these types of tasks possible.
When first accessing the Filter specification screen, you will be brought to a listing of existing filters for the selected application. From this page you can edit, delete, or reorder any existing filters.
Additionally, you can create a new filter by clicking on the “Add Filter” button. Clicking “Add Filter” will open the following screen:
Filter Type
Prior to making any filtering choices, first choose what type of filter you want to create.
Choices include:
- Hard-Coded Value — This means that the developer will be specifying a specific value(s) within the application.
- Prompt at Runtime (available in reports/summaries) — Developers can defer the filtering choice to the end-user at runtime.
- Row Level Security — Utilize user-specific data to add security this application, ensuring that the end-user can only see data applicable to him/her.
Filter on Field
Select the desired field. This list is populated by all fields currently selected in the application build process.
Relation
Select the desired relationship:
Filtering on Dates
When a true date field is selected as the filter field, new date specific options become available for the relationship dropdown. Common date values include today, yesterday, this month, etc.
To allow the end-user to perform runtime period analytics where they can compare date ranges against one another, use the ‘Period Analysis’ relationship. Full documentation on this feature can be found here.
Value Type
Constant Value
The “Constant Value” option is the basic Filter screen. By default, when creating any application you will have the option, as developer, of specifying a constant value as a filter for this application.
Application Field Value
The “Application Field Value” option allows you, as a developer, to specify a filter by comparing one field in your application to another field. You can only compare like fields (Numeric to Numeric, Alpha to Alpha, etc.). In addition, only certain relationships will allow this comparison option. When a relationship is not allowed, “Application Field Value” will be removed from the Value drop-down option.
The relationships that allow this comparison are:
- Equal
- Not Equal
- Greater than
- Greater than or Equal to
- Less than
- Less than or Equal to
- Not greater than
- Not less than
- Contains
Prompt at Runtime
The final option you have for filters as a developer is to allow the end-user to decide at runtime what their filter should be. This option is called “Prompt at Runtime”.
Value
Enter a value, as necessary.
If choosing “Constant Value”, input a value. This value, which the end user cannot change, will be compared to the field based on the relationship chosen.
Choosing “Application Field Value” will allow you to select another field in your application to compare against the previously selected field.
If you would like your end-user to have the option of inputting a value at runtime, click “Prompt at Runtime”.
Default Value
When utilizing the “Prompt at Runtime” option for filters, you have the option of defaulting a value. At runtime, the entered default value will display in the runtime filter input. The end-user has the option of changing this value if wanted. If using run=2 and not specifying a value for the filter, the default value will be used.
And/Or
Select “And” if you would like the the application to be filtered by the current filter and the subsequent filters. Select “Or” if you would like the application to be filtered by either filter.
Reordering & Grouping
WHERE or HAVING
Applicable only to report templates, you have the ability to specify your filter as a HAVING filter, rather than the default WHERE clause.
HAVING allows your filter to be applied to the subtotal level, rather than the detail level.
For example, suppose you have a report built over the sales history file and you had selected the Customer Number as the dimension. Assume customer ABC had 5 rows, each showing sales for $5,000.
Using a filter type of WHERE (the default) and specifying a filter of sales greater than $8,000 would yield no results since none of the detail level rows are greater than $8,000.
However, changing to a filter type of HAVING would show data as the total sales for customer ABC would be $25,000 which is more than than the $8,000 HAVING filter.