Skip to main content

Filter-only fields

Refer to the Filter syntax reference for more information about filter syntax.

aliases:

Similar to table level aliases, occasionally a field name may change in your database, which can cause content to break. To fix this, we can add aliases: to the field in question pointing references from the old field name to the updated field name, restoring content and eliminating content related errors. This behaves similar to table level aliases, as shown

bind_to:

List of field names that this filter-only field’s filter expression should be applied to. When a filter is applied to this filter-only field, the filter expression will be applied to each field in this list—filters on dimensions go to the WHERE clause, filters on measures go to the HAVING clause. For more information, see Templated filters.

default_filter:

  • default_filter will automatically populate the filter value in the templated object
  • This is often paired with filter_single_select_only and suggestion_list when a single-selection is required
  • For setting the filter arguments, use the filter syntax

description:

  • Metadata about the field, made available in the workbook/dashboard table UI upon hovering over a field with a description, or on right click from the field picker
  • Omni expects unquoted text (quotes will be removed / ignored)

display_order:

  • Omni expects a whole number
  • This will override the sort order for the field picker, inside the field’s grouping (i.e. inside a given view)
    • display_order will supersede alphabetical sorting
  • For example, if the two fields above in users are given display_order: they will float to the top of the field list in users, and the remaining fields would be sorted alphabetically
  • To rearrange views, display_order can be used at the view level
  • For fields inside groups using group_label, the group will be ranked with the min of all the fields in the group (i.e. if there are 3 fields with display_order of 4, 5 and {empty}, the group will have a display_order of 4)

filter_single_select_only:

  • This argument will require the filter field to use a choose-one dropdown rather than the default flexible filter modal
  • Recommended with templated filters that require one-and-only-one object

group_label:

  • This will nest a group of fields in the field picker for curated organization
  • Omni expects unquoted text (quotes will be removed / ignored)
  • Note measures and dimensions will still be in separate sections in the field picker under each view
  • Fields can be nested under timeframes using the group label - the text rather than the field should be used (i.e. Created At not created_at)

hidden:

  • Remove the field from the UI. Still referenceable in the model, but hidden in the workbook UI.
  • Expects ‘true’ or ‘false’

ignored:

Likely should not be used with filters, can just delete or comment out if it’s not desired in the model

label:

  • Label will override the field name for all UI appearances of the field
  • Omni expects unquoted text (quotes will be removed / ignored)

required_access_grants:

You can also conditionally allow access by using pipes (|) and ampersands (&) to create OR and AND conditions.

suggestion_list:

  • Suggestion list will explicitly set the suggestions on

suggest_from_field:

  • This argument can be used to populate a filter with another field’s values
  • Commonly used when the filter is injected in sql with a corresponding modeled field

suggest_from_topic:

  • This needs to be paired with suggest_from_field and can tune the specific topic (ie access-filters and default filters) for a given suggestion

type:

  • Currently, filter-only fields can only be defined in the IDE. They require a name, and a type. The accepted types for a filter-only field are:
    • boolean
    • column (returns unquoted text, can be used to substitute in column names in query views)
    • number most common
    • string most common
    • timestamp most common

view_label:

  • This will nest a given field under a different view than its default parent view, for example, grouping user_facts fields under the users view for better organization and discovery
  • Note that filters will always be below dimensions and measures
  • Sometimes can be valuable to pull all filters into a separate pseudo-view, would do that with the view argument as seen here