Parameters

The Parameters tab configures incoming parameters and fixed filters: together they provide controlled data filtering at the dataclip level. All filtering logic is combined using AND conditions.

Incoming parameters define filterable inputs for specific dataclips; fixed filters assign values to those parameters automatically.

Incoming parameters

An incoming parameter defines a filter input for one dataclip and one header (field) within it, letting an internal or external process inject a value that filters the dataclip’s data. Each parameter is strictly bound to that single dataclip/header combination.

Setting	Required	Description
Name	Yes	Recognizable identifier of the parameter.
Description	No	Informational description for management purposes.
Dataclip	Yes	The dataclip the parameter applies to.
Header	Yes	The specific header (field) within that dataclip.
Required	No	If enabled, data won’t load unless the parameter receives a value.

The parameter’s type is implicitly determined by the selected header’s type (a numeric header gives a numeric parameter, a date header a date parameter, and so on).

Multiple parameters can target the same dataclip; when they do, they’re combined with AND logic, for example CustomerId = 5 AND Status = 'Open'. Use Required when exposing sensitive datasets, to prevent them from loading without proper filtering: the dataclip won’t load data, and a message or log entry indicates the missing parameter.

Incoming parameters can receive their value from a fixed filter, or from a navigation flow.

Fixed filters

A fixed filter assigns a value to an incoming parameter automatically: it’s not a direct data filter, but a controlled parameter injector, configured per form in the Parameters tab.

Setting	Required	Description
Incoming parameter	Yes	The parameter the value will be assigned to.
Type	Yes	Determines how the value is generated (see below).
Additional settings	Depends	Additional configuration depending on the selected type.

Supported types:

• Static: a fixed value you enter manually, for example hardcoded filtering like Status = Active.
• User: the signed-in user’s User ID, to restrict data to records owned by the logged-in user.
• Username: the signed-in user’s username.
• Variable: a value from a user-specific variable. If the variable can be modified by the user, the resulting filter may change based on their input.

Fixed filters aren’t directly visible to end users (only in logging) and can’t be edited by them: though a variable-based filter may still change indirectly if the underlying variable is user-editable.

Execution flow: a fixed filter assigns a value to an incoming parameter, that parameter binds the value to its dataclip/header, and the dataclip applies all its parameter filters together using AND logic, for example UserId = 12 AND Department = 'Sales'.

Best practices

• Use Required for sensitive datasets.
• Use the User type for row-level security.
• Avoid multiple parameters targeting the same header.
• Use variables carefully when allowing user-editable values.
• Keep system-driven filters (fixed filters) logically separate from navigation-driven parameters.