Data filtering

Before metrics are displayed in a form, the data is filtered.

At runtime, before the query is run,
  • The $$RECORDID$$ filter is replaced by the record ID of the parent record that the form is being displayed within.
  • A $$PARENT::[Section]::[Field]$$ filter is resolved to the defined parent record field’s value.
  • If a metric query is displayed outside of a parent record, any parent-sensitive filters, such as $$RECORDID$$ and $$PARENT::[Section]::[Field]$$ are ignored.

Define $$RECORDID$$ and $$PARENT::[Section]::[Field]$$ filters against fields that are defined as a drill path in the fact table. The metric that is filtered for a program or a classification, and that uses these filters, acts similar to selecting from the drill path list. It also filters for the specified record and includes all children of that record.

When a $$PARENT::[Section]::[Field]$$ filter value is specified on a hierarchical filter, a null parent field is the equivalent of choosing the root node of the drill path. It also includes all of the records that match the root value. A non-hierarchical filter behaves much like a business object query filter and filters for records with null value when the parent field value is null.

$$RECORDID$$ and $$PARENT::[Section]::[Field]$$ filters behave as if they are runtime filters except that their value is passed from the parent record.

If a metric query has $$RUNTIME$$ and $$PARENT::[Section]::[Field]$$ filters that are defined against the same field, when the query is displayed inside a form, the $$RUNTIME$$ filter control is not used. Instead, the value from the$$PARENT::[Section]::[Field]$$ is used as the filter value.