Decision Filters

Learn about the use of decision filters.

Decision filters can be used for the following purposes:

  • To use different field groups in the quick add based on the source data of a single article.
  • To use different MiniDetails actions or default actions based on the record's data in a RecordListView.
  • To define quick actions for objectives.

A Decision filter has several sub-info area nodes of the same info area, each with conditions and properties.

Example: Decision Filter for the Quick Add

You can specify a Decision filter in the new FieldGroupDecider input argument (Serialentry action call).

In the following example, items with an Item No. between 1000 and 1999 does not apply the field group defined in the SerialEntry action call but the ones defined in the following Decision filter (i. e. AR2, UP2, and LP2).



The SourceFG (AR2), DestFG (UP2) and DestChildFG (LP2) parameters are applied to all items within the Item No. range from 1000 to1999. These parameters override the "default" field group assigned in the SerialEntry action call.

You can also define multiple sub-info area nodes for multiple conditions.

You can define the following parameters:

  • Parameter:SourceFG: Overrides SourceConfigName (List-Control)
  • Parameter:DestFG: Overrides DestinationConfigName (Edit-Control)
  • Parameter:SourceChildFG: Overrides SouceChildConfigName (List-Control)
  • Parameter:DestChildFG: Overrides DestinationChildConfigName (Edit-Control)

Decision filters only affect the display of data, the quick add business logic remains unchanged and is still defined in the field groups and in the action calls:

  • All fields must exist in both, the field groups referenced by the filter and the ones assigned in the action. Fields that do not exist in the field group assigned in the action call are ignored.
  • If fields are only needed for the filter, you can set the Hide Field field attribute in the field group.
  • Function names and the Don't save and Don't save offline field attributes cannot be overridden by a Decision filter.
  • You can define different (alternative) labels.

Example: Decision Filters for RecordListview

Decision filters can be specified in the DetailActionSwitchFilterName input argument (RecordListView action call).

In this example, the record's default actions are based on the ABC field's value. The defined default actions used are applied to the corresponding records. Additionally, for "C" companies an additional quick action is available in the MiniDetails.



You can define the following parameters:

  • Parameter :DefaultAction: Defines the alternative default action (context menu action) that is executed instead of the standard default action.
  • Parameter :DefaultActionButton: Defines the alternative button instead of the default button. The action assigned to this button is executed.
  • Parameter :Action: Defines one or more context menu action that are displayed as additional quick actions for the MiniDetails.
  • Parameter :ButtonAction: Defines the buttons that are displayed additionally in the MiniDetails.

Decision Filters in Quick Actions for Objectives

If you use Decision filters in quick actions for objectives, define them as described in Example: Decision Filters for RecordListview.

However, only the following two parameters are available:

  • Parameter:Action
  • Parameter:ButtonAction

Assign the Decision filter to the ExecuteActionFilterName input argument of the ObjectivesEditView action call, see ObjectivesEditView.

Allowing Adding/Editing Records Only in Online Mode

You can define that a user is only allowed to add or edit records when in online mode.

You can: