Data Gathering ABC / App Task

Introduction

An Application Business Component (ABCs) is a pre-fabricated software product that serve as a Solution building blocks. It solves recurring business problems out-of-the-box, can be used for a wide range of business scenarios thanks to powerful configurations, and comes with continuous evolution that is taken care of by FNZ Studio.

The Data Gathering ABC, in particular, provides an intuitive and fast approach to gathering client data for business cases of any complexity, from simple forms containing a couple of fields to the most complex KYC with hundreds of structured fields.

Its functioning is based on a declarative, data-driven approach: the runtime UI is autogenerated according to mapping strategies specific to the Data Gathering business requirements. No other screens or components are required, which drastically reduces the time and effort dedicated to configuration. Such configuration is performed on the Data Gathering App Task, a category of Process Tasks that comes with its own User Interface built as a single-page application. Such UI is entirely generated based on Data Class Business Object and Data Logic Business Object Business Objects. App Tasks can be combined with other App Tasks and "traditional" Process Tasks in the same Process Instance to cover all the requirements of Solutions.

Installation and Upgrade

App Task Access

The access to an App Task is managed through Users, Groups and Roles. As with all types of Process, you can define Swimlane in your App Task, and each Swimlane can be associated with one or multiple Participants. Such Participants are the Users, Gruops and Roles defined in FNZ Studio for Access Control.

Anonymous User Access

Anonymous users can access specific features of the Data Gathering App Task. This is to allow unregistered users to access some specific tasks. Note, however, that access is forbidden for certain features, as described in detail below.

To allow anonymous users, do the following:

1. Do not add Swimlanes to your Process
2. Enable the nm.workspace.resource.filetypes.anonymousaccessallowed configuration property.

Anonymous user access is granted to the Data Gathering App Task with the exclusion of these ABC features (note that Data Review features, such as Review Requests, are always excluded):

• App Tasks: Common Configuration
• Comments
• Change History

Session Expiration and Re-Login

When users work on FNZ Studio Runtime, it can happen that their session expires, for example when the they are inactive for some time. In this case, App Tasks show a dedicated error banner with a configurable error message and a button to resume the work.

Installation

Ingredients and Installation Steps

Data Gathering consists of the following basic ingredients, which should be installed in this order:

1. AppTask Extension (included in FNZ Studio (Core) installations)
2. AppTaskAPI Extension (included in FNZ Studio (Core) installations)
3. DataGathering Extension
4. (optional) WorkspaceCollaboration Extension (if using Collaboration: Comments and Review Requests).

Technical Requirements

Make sure you check the following:

• You are on a compatible FNZ Studio Core version. See the Data Gathering Product page for compatibility information.
• Your FNZ Studio installation includes all other mandatory extensions (in addition to AppTask and AppTaskAPI) and Packages. See FNZ Studio 2025 System Upgrade guide.

Upgrading to Data Gathering 2025

When upgrading to the latest available Data Gathering 2025 release (2025.1.x) from a lower version, you may need to consider the following information:

Upgrading from Data Gathering 2025.2 to 2025.3

The default text of the following Label has been changed. If you are already using this Label in your Solution, you need to edit its translation manually in FNZ Studio Composition (Solution Design > Translations tab):

• AppTask:ErrorTrigger.Message (default text changed from "There are X error/s" to "X errors")

Upgrading from Data Gathering 2025.1 to 2025.2

The following Labels have been added in Data Gathering to the Platform Package specified in the Label with default English texts. You can add and edit translations for such Labels (in Solution Design> Translations tab):

• AppTask:Components.NoItemAvailable (default text: No item available)

• DataGathering.DataClass.AddItem(default text: Add new element)

• DataGathering.DataClass.AddItemExtended (default text: Add new element)

Upgrading from Data Gathering 2024.5 to 2025.1

The following Labels have been added in Data Gathering to the Platform Package specified in the Label with default English texts. You can add and edit translations for such Labels (in Solution Design> Translations tab):

• AppTask:FileMessages.Upload.Success(default translation: Uploaded!)

General Properties

After following the installation steps described above, the Data Gathering App Task will be available in the Process Editor. You can drag and drop it into the central composition area, as shown in the image below.

Data Gathering App Task in the Process Editor

Data Gathering App Task in FNZ Studio Runtime

Process Properties

Most of the general properties of the App Tasks (title, type, and so on) can be set in the Process Editor, as illustrated in the table below.

Property	Description	Configuration
App Task Title (Process Editor)	Name of the Data Gathering App Task in the Process Editor (Data Gathering in the first image above).	Process Editor Properties tab > Name field.
Page Title (UI)	Name of the App Task page in FNZ Studio Runtime	Process Editor Properties tab > Runtime Title field (Account 1234 in the second image above). You need to select a Label Business Object. In case the property is not set, it shows 'FNZ'. This property is mandatory for App Tasks included in Ad-Hoc Sub-Processes, in which case, the page title is displayed at the top of the content area.
App Task Title (Task List)	Name of the page on a Task List (backend) Process Editor.	Properties tab > Task List Name field. You can select a Label Business Object or enter a text. Set the name of the page, as it should appear on a Task List (it may contain a Label or not).
Type of App Task	Type of navigation pattern to use inside the App Task	Properties tab > Task type dropdown. Select the Task pattern between Sequential (tasks form a linear sequence, where users navigate through each Task step-by-step, and can typically only move forward or backward) and Drill Down (multiple different Sub-Tasks can be opened from one main Task). This influences navigation and page structure. See configuration details.
App Task initialization	Logic to be executed when initializing the App Task	(optional) Properties tab > Setup Script field. Specify the Script Function Business Object that contains the logic to be executed when initializing the context of the App Task (if any). This can be used, e.g., to set any necessary Process Instance or Token Attribute. The script is executed once for each token when it becomes Active.

Home Button

The Home button is rendered as the logo on the top-right of the FNZ Studio Runtime page.

The Home button is not configured in the App Task, instead it is managed by the global configuration property nm.window.start. If you do not set this property, the FNZ logo is shown by default.

Feature Overview

Following is an overview of the main Data Gathering features. The sections below will provide detailed information on each feature and how they are configured.

1. Navigation and Actions (1) — A bird-eye overview of the page structure allows you to find fields easily. Moreover, actions allow going back or forward in the process, deleting items or move to a different task, among others. See Navigation and Actions section

2. Content Entry/Editing (2) — The content area UI guides the end user in filling forms easily. See the Content Area section. In this area, the users can:

   • Enter and edit data through input fields and be guided through text information
   • View change history
   • Search objects (parties)
   • Upload files

3. Content Structure (3) — On the developer's side, content can be structured in sections and groups to make the end user work easier. Moreover, content can also be arranged through tables, summaries and files organized in folders. See the Content Structure section.

4. Information framework (validation) (4) — Continuous feedback and annotations are provided on blocking issues and warnings, as long as suggestions on how to fix them. See the Information Framework: Validation section.

5. Collaboration (5) — Comments and Review Requests provide an easy way for reviewers to cooperate among them and with editors. See the Collaboration: Comments and Review Requests section.

6. Developer Toolbar (6) — The Developer Toolbar provides three main tools: the Theme Editor, which allows styling your Solution; the Inspector Tool, used to navigate to the Business Objects where the elements of the current page in FNZ Studio Runtime are configured and fixed any issues; the Integration Console, which shows all the integration calls performed for easier contextual debugging. See the Developer Toolbar section.

Navigation

Feature Overview

A bird-eye overview of the page structure allows you to find fields easily.

Navigation in Data Gathering is based on the following elements:

1. Page Structure (Sidebar and Action position): Page structure determines the way the Data Gathering page is organized (whether there is a sidebar or not) and where Actions are positioned on the page itself. Page structure is configured through a combination of the following elements:
   • Task Type: The Task Types property (Sequential or Drill-Down) set at Process level determines where Actions are positioned on the page.
   • Ad-Hoc Sub-Process: If a Data Gathering App Task is contained in an Ad-Hoc Sub-Process Component, a navigation sidebar may be displayed. With the Sidebar, users are constantly provided with an overview of the steps that are needed to reach the end of the process. They can either follow a predefined path or jump to a specific step directly by clicking on any task.
2. Content Navigation (Tab Bar): The Tab Bar allows users to navigate through different pages (e.g., customer pages). This type of navigation is specific to Data Gathering and is configured through the Data Logic BO.

The following sections illustrate configuration details.

Page Structure

Configuration

As mentioned above, the way the data gathering page is structured and the position of Actions on the page depends on a combination of the following elements:

• Task Type: Sequential or Drill-Down . This property is set in the Data Gathering Process Properties.
• Ad-Hoc Sub-Process: The Data Gathering App Task (and other Process Components, if any) may be contained in an Ad-Hoc Sub-Process. In this case, each Process Component included in the Ad-Hoc Sub-Process may be rendered as an item in a navigation sidebar. See Ad-Hoc Sub-Process configuration details.

There are four types of page structure depending on each configuration type, as illustrated in the images below:

Mode 1: No sidebar is shown; all Actions are displayed at the bottom center of the page.

• Task Type: Drill Down
• Data Gathering App Task inside an Ad-Hoc Sub-Process

Mode 2: Sidebar is shown; all Actions are displayed in the sidebar.

• Task Type: Sequential
• Data Gathering App Task inside an Ad-Hoc Sub-Process

Mode 3: No sidebar is shown;Back Action is displayed at the top left of the page, Custom Actions are displayed at the bottom center of the page.

• Task Type: Drill Down
• Data Gathering App Task outside an Ad-Hoc Sub-Process

Mode 4: No sidebar is shown; all Actions are displayed at the bottom center of the page.

• Task Type: Sequential
• Data Gathering App Task outside an Ad-Hoc Sub-Process

Content Navigation (Tab Bar)

Configuration

The Tab Bar allows users to navigate through different pages (e.g., customer pages). This type of navigation is specific to Data Gathering. The Tab Bar is configured through Section Group Controls in the Data Logic Editor (see Data Logic Business Object). Two different navigation modes are supported, based on the level of nested groups (as illustrated in the images below). Note that Section Group Controls also determine how data is grouped on a page (see Content Structure section for details).

Mode 1:

• Section Group Controls: Not nested

Mode 2:

• Section Group Controls: Nested

Actions

Feature Overview

App Task Actions allow developers to define all aspects of an Action in the Process editor directly. This allows reusing the same Data Logic in different situations, and with different actions. Moreover, only the Process Business Object is altered when actions need to be added, removed, or updated.

App Tasks Actions may be of three types (configuration details are illustrated in the table below):

Configuration

Data Gathering Actions are configured in the Actions tab of the Data Gathering Process Editor.

UI element	Description	Configuration
Back Action (1)	Back button. Depending on the type of type of App Task, it may be visible at the at the top left or at the bottom center of the page.	This is a predefined, static Action, which allows ensuring a consistent developer experience across different solutions. It is configured in the Actions tab > Global Actions > Back option. See Predefined Actions (Back).
Custom Action (2)	Any kind of Action applied to the Process (e.g., Go to documents, Ask for help)	This Action is entirely defined by the developer. It is configured in the Actions tab > Global Actions > Custom Actions option. Two types of Custom Actions are available: Process (impacting the Process flow by moving the token) and Script Actions (reload/update actions with no impact on the Process flow). See Custom Actions.
Inline Action (3)	Action available for a specific field or section in the UI (Go to personal file next to the client's data section).	It is configured in the Actions tab > Inline Actions option. Two types of Inline Actions are available: Process (impacting the Process flow by moving the token) and Script Actions (reload/update actions with no impact on the Process flow). See Inline Actions.

Content Area

Feature Overview and Configuration

The content area is where the end user enters data, which is the main activity in the context of Data Gathering, and is typically done by using forms. Forms may contain different types of item such as, text fields, date pickers, dropdown lists, and so on.

All the elements included in the content area are configured starting from Data Logic Controls. The Primitive Types configured in the Data Logic are mapped into input control elements such as text, date picker and so on. Data Logic Rules may also apply to certain Primitive Types.

For example, a text field component is displayed when the Primitive Control is of type String, while a date picker is displayed when the Primitive Control is of type Date (without any Data Rules configured).

On the other end, to render a dropdown list, you will need to set a Primitive Control of type String (or Integer, Date, Float etc.) and add a Catalog Values Rule with the Size property set to can return a large number of results.

See more information on :

• List of App Task Primitive Types and their configuration.
• Details on Controls Tab configuration.

Input Fields

Feature Overview

As mentioned above, the content area may contain different types of input fields to enter information such as, text fields, date pickers, dropdown lists, and so on.

It is possible to provide extra information (info text, tooltips and so on) for each input field to help the user fill it correctly.

Configuration

UI element	Use	Configuration
Input field(1)	Each component used to fill in a form (text field, dropdown list, radio button and so on).	Primitive Types (e.g., String, Boolean, Date) are mapped into input control elements (e.g., Text, Radiobutton, Date Picker) and configured through Data Logic Rules (e.g., the Size Rule determines the number of returned items). See Primitive Types.
Label(2)	Short text providing basic information on a field	Data Logic Controls - Label property. See Labels and Translations.
Extended Label(3)	Extended text providing additional information on a field (e.g., tips on the correct value to enter or select). It is shown while the end user is editing the field.	Data Logic Controls - Extended Label property. See Labels and Translations.
Tooltip/Infotip(4)	Text providing additional information on how to fill a field. It is not shown while the end user is editing the field.	Data Logic Controls - Information Label property. See Labels and Translations.

Change History

Feature Overview

Data Gathering provides the ability to inspect the history of entered and changed data at field level.

To see the history of changes for each field:

1. Hover on the field and click on the 'clock' icon to trigger the Change history popup.
2. The Change history popup contains the editor's information, and the date and time of change in a timeline. The latest change is highlighted and is always at the top of the timeline.

Configuration

Change History does not require further configuration. However, you need to enable the feature by selecting the History Enabled checkbox in the Data tab of the Process Editor. If selected, change history is enabled for all fields from the tracking start point. You can also enter a Script Function to enable it dynamically.

Text Information

Feature Overview

When it is necessary to provide extra information to end users to support them in the process, a possible option is to add a Text Control in the Data Logic Editor. We recommend using a Text Control in the following cases:

• Long instructions
• Instructions that affect several fields
• Instructions that contain a computed value
• Warnings caused by external factors (and not by the App Task fields themselves)
• Success information

Configuration

Text information is configured through a Data Logic Text Control with itsType property set to one of the following values (see figure above):

• Plain text
• Information
• Alert
• Success

Object Search

Feature Overview

You can search for and add elements from an existing Collection (external or not) or Single Element in the Data Gathering App Task. The main use case in Data Gathering is Party search, however it is possible to search for any Object.

1. To search for existing Parties (or other Objects) in a collection, click on the Add existing [Party] button on the main data collection page.
2. The Search modal window is opened. Enter the desired text in the search bar (1) and click the Search button to view results (2).
3. Click on the [Select] button to actually add the Objects to the collection (they are moved to the Selected [Parties] area (3)).

Configuration

To set the Search feature in your Data Gathering:

1. Configure a Data Logic Search Data Rule. This governs both Search Criteria and Search Results, as illustrated in details in the table below.
2. The configured Data Logic BO must then be referenced in the Data tab of your Data Gathering Process Properties
3. See the following table for further configuration details on each search item (see image above):

UI element	Use	Configuration
Search Criteria (1)	Area where you enter search data. You may have a basic search bar (a Type dropdown and a free-text search field) or custom search criteria.	The Search Mode setting in your Search Data Rule determines whether you have basic search or advanced search (configured through further settings). See Search.
Search Results (2)	Area where search results are displayed.	The Search Results setting in your Search Data Rule determines how search results are structured (based on a linked Data Logic Business Object). See Search and the note on Search Results* below.
Selected Objects (3)	Area displaying the selected objects.	A Summary Behavior associated with your Data Class (e.g., Party) determines the card layout. See Summary Mode (Summary Behavior) .

*Note on Search Results: The columns displayed in the Search Results table are computed merging all the Data Logic Controls set in the Data Logic Business Object. The merge logic is based on the Control Label ID, meaning that two Controls with the same Label Id are merged in one column. In the example below, you may have String Controls Company Name and Party Name with matching Label IDs and, thus, they are shown under one Name column. At the same time, you may have String Controls Party Name and Party Middle Name with matching Label IDs, meaning that, even in this case, only one Name column is shown.

File Uploading

Feature Overview

The Data Gathering App Task provides features for file uploading. These are provided by the File Uploader Component (see File Uploading).

Configuration

The configuration of the File Uploader consists of two steps:

1. Blob Storage configuration. This step is usually performed by your system administrator (see Blob Storage Configuration).
2. Data Class configuration. The configured Data Class must be contained in your Data Logic Business Object as a Data Class.

To configure a Data Class for file uploading, you need to perform the following operations:

1. As a prerequisite, you must declare a dependency on theBlobPlatform Packages in the properties of your current Package.
2. Add a property of type Blob:File or Indexed Blob:File to your Data Class. In the Properties tab of your Data Class (e.g., Passport), select Blob:File as a Type. For indexed collections, select Indexed Elements as a Collection Type.
3. Optionally, define any constraints on the type and maximum size of the files that can be uploaded. Such constraints must be defined in a Catalog Business Object containing columns named exactly MediaType (e.g., image/jpeg) and MaxSize (e.g., 5000). The configured catalog BO must be selected in the File Constraints property of your data Class.

At this point, a File Uploader is in place. However, you can use a Document Behavior to add Solution-specific business metadata, as well as organize files in folders. See the Document Organization (Document Behavior) section for details.

Content Structure

When building a solution that uses Data Driven UIs, the User Interface is automatically generated based on:

• The specific App Task used in the Process, such as the Data Gathering App Task
• The business logic defined in one or more Data Logic Business Objects
• The data model defined through Data Classes

When the Data Logic is translated in a data-driven UI, controls are rendered as form elements by default.

Moreover, you can structure content based on:

• Field Sets and Sections — Allow grouping related fields together on a single line or in a card. These are configured through Data Logic Controls.
• Display Modes — Allow showing data in tiles, tables, or folders. These are configured through Data Class Behaviors (Summary, Table Row and Document, respectively).

Field Grouping

Feature Overview and Configuration

When gathering data, you may want to group some correlated fields together. There are basically two ways in which you can group fields, and both are configured through Group Controls in the Data Logic BO.

1. Field Sets — These are fields which are strongly correlated semantically and can be shown on the same row. Such elements are represented as part of the same group, e.g.: start date/end date; zip/city; street/street number; amount/currency. These are configured through the Field Set Group Control in the Data Logic BO. See Section Group / Field Set Group.
2. Sections — Sections group specific fields together, e.g., all the fields for the KYC, or all the fields regarding the family of a party (first name, last name, date of birth). Starting from Data Gathering 2024, these elements are grouped through a card layout. Sections are configured through the Section Group Control in the Data Logic BO. Note that Sections Groups are also used by App Tasks to structure page navigation, as illustrated in the Navigation section.

Summary Mode (Summary Behavior)

Feature Overview

Data (e.g. a list of addresses) may be shown in two different modes in the UI:

1. Condensed Mode (1) — (default) Only a predefined subset of data is shown in read-only mode and cannot be edited by the user. This is obtained through the Summary Behavior, which allows organizing data in a list of entities in order to have a condensed view of a large amount of information (e.g., a list of addresses).
2. Extended Mode (2) — All data contained in the list is shown. Data can be edited and the user can delete a whole item from the list.

Configuration

Behaviors are configured at Data Class level. A Behavior defines the way in which a certain Data Class behaves when it is represented in an automatically-generated UI.

Following is an example of a Person Data Class, containing a property addresses of type Indexed Address, where Address is another Data Class containing the address information items country, city, street and number.

To configure a Summary Behavior for your Data Class, you first need to got to the Behaviors tab of your Data Class and drag a Summary Component to the edit area. The table below summarizes how to configure each item.

UI element	Use	Configuration
Card icon (1)	Icon or image representing the content of the card	Icon Type / Icon Id / Resource Id properties (Configuration tab). Icons can be chosen from the set of default icons provided by FNZ Studio or by selecting a Resource Business Object.
Card title (2)	Title displayed on top of the card.	Title property (Configuration tab). It can either be chosen from the String properties of the Data Class, or defined using a Script.
Contextual information (Key-value pairs) (3)	Additional contextual information displayed in the auto-generated UI as key-value pairs (e.g., Country - [Country code])	Label - Value properties ( Labeled Values tab). Each Label is a Label Business Object representing the name of the field, and each Value is the value written next to the label. The value can either be a property of the Data Class or can be built using a Script.
Additional information (unstructured) (4)	Additional values to be shown in the Auto-generated UI (e.g., street, city)	Unlabeled Value properties (Unlabeled Values tab). Each value can either be a property of the Data Class or can be built using a Script. You can reorder Unlabeled values through drag-and-drop.

Tables (Table Row Behavior)

Feature Overview

Tables in Data Gathering can be used to visualize complex collections with a small/medium number of elements.

Each element in the Collection is represented by a row in the table. Rows can also be expanded to show child Collections (if configured). Finally, you can decide whether to add and edit table items inline or in a modal window (see image in section below).

Configuration

To have a table rendered in your Data Gathering, you need to perform the following basic steps:

1. Configure a Data Logic Business Object with a set of Data Logic Primitive Controls. Each Primitive Control (e.g., Name, Status, AMU) will be added as a column in the table. The Data Logic BO governs additional properties such as the order of columns (Control sorting), their header (Labels) and their visibility (Sentries).

   

2. Table organization is governed by the Table Row Behavior. You will need to add a Table Row Behavior for each Data Class (e.g., Models in the image below) that can be part of the Collection. This is done in the Summary tab for each Data Class.

3. The configured Data Logic BO must then be referenced in the Data tab of your Data Gathering Process Editor.

4. Configuration details on each item (numbered in the images below) are illustrated in the following table:

UI element	Use	Configuration
Table Column(1)	Each column represents a property, such as Company Name, Status, and so on.	Each column corresponds to a Data Logic Primitive Control. Note that Data Class Controls are ignored. See Primitive and the note on Column merge below.*
Expandable Row(2)	Each row represents an element in the Collection. The row can be expanded to display any child items.	Expand Row Content setting in the Table Row Behavior (Configuration tab). You can select Data Classes with Collection Type Indexed (Primitive Types are not supported). Note that Data Gathering renders the expanded row only if the child Collection has at least two Controls (columns) in common with the father Collection (e.g., Name and AMU in the image above).
Table Column - Sums(3)	Columns containing properties that should be summed up.	Accumulating Properties setting in the Table Row Behavior (Accumulating Properties tab). You can select Data Class properties of type Double/Float/Integer/Long/BigInteger/BigDecimal.
Inline Actions(4)	One or more actions available at row level (Delete, Add Table, and so on) upon clicking on the three-dot menu.	Actions tab of your Data Gathering Process Editor. Note that these are only supported for Collection elements (row level) and not for single fields (cell level). See Inline Actions.
Create/Edit Mode(5)	You can decide whether to add and/or edit table rows inline or in a modal window.	Create/Edit Element Inline setting in the Data Logic Collection Control. See Collection.

*Note on Table Columns: Consider the column merge logic: the columns displayed in the table are computed merging all the Primitive Controls set in the Data Logic Business Object. The merge logic is based on the Control Label ID and Type, meaning that two Controls with the same Label Id and the same Type are merged in one column. In the example below, you may have String Controls Company Name and Party Name with matching Label IDs and Types (both are String) and, thus, they are shown under one Name column.

Document Organization (Document Behavior)

Feature Overview

The Data Gathering App Task provides the File Uploader Component for basic file uploading, as illustrated in File Uploading.
However, the Document Behavior provides advanced file uploading features, such as adding Solution-specific business metadata to your uploaded files, and organizing documents in folders.

Configuration

1. To use a Document Behavior, you first need to configure file uploading, as illustrated in File Uploading above. You will, therefore, have a configured Data Class which must contain containing at least one property of type Blob:File or Indexed Blob:File.
2. Go to the Behaviors tab of your Data Class and drag a Document Component to the edit area. The table below summarizes how to configure each item.

UI element	Use	Configuration
Folder title (1)	Title displayed on top of the card to indicate the document folder (e.g., Passport).	Title property (Configuration tab). It can either be chosen from the String properties of the Data Class, or defined using a Script.
Contextual information (Key-value pairs) (2)	Additional contextual information displayed in the auto-generated UI as key-value pairs (e.g., Issue Date - [Issue date of the uploaded document])	Label - Value properties ( Labeled Values tab). Each Label is a Label Business Object representing the name of the field, and each Value is the value written next to the label. The value can either be a property of the Data Class or can be built using a Script.
Business metadata (3)	Business-related information attached to the file (e.g. Document type, Issue Date, Issuing Authority, and so on) that the user can fill while uploading the document.	All the properties of the configured Data Class other than Blob:File or Indexed Blob:File represent business metadata .

Information Framework: Validation

Validation Overview

The information framework in Data Gathering provides continuous feedback and annotations on the fixes and actions necessary to continue in the data gathering activity.

The information framework consists of two different types of validation:

1. Sidebar (Ad-Hoc Navigation Validation) (1): The sidebar shows the validation status of each step in the navigation (i.e. if the step is complete or incomplete). This way, the user is provided with an overview of missing steps and can take action to complete all their tasks. See Navigation Validation (Ad-Hoc Sub-Processes)
2. Tab Bar/Violation Panel/Content Area (Content Validation) (2): These three areas highlight the violation of predefined rules at content level (missing or unexpected data, wrong data format and so on). This way, the user can address and correct any issues and continue with their data gathering activity. See Content Validation (Data Logic).

Navigation Validation (Ad-Hoc Sub-Processes)

Feature Overview

The sidebar shows the validation status of each step in the navigation (i.e. if the step is complete or incomplete). When validation is configured, users are provided with an overview of errors and can quickly take action where needed. Valid/ invalid Navigation Items are visually indicated by a badge.

Configuration

To have navigation validation rendered in your Data Gathering, you need to perform the following basic step:

1. Your Data Gathering App Task must be contained in and Ad-Hoc Sub-Process Component.
2. Go to the Ad-Hoc tab of your the Data Gathering Process Editor and configure Validation Badges as described below.

Property	Configuration
Validation Badge Required checkbox	Select this checkbox if you want validation badges to be shown. If a Validation Badge is configured on a Navigation Item, a (red/green) badge may be shown based on the configuration set by the developer (e.g., a green badge indicates there are no blocking issues, a red badge indicates there is at least one blocking issue).
Validation Badge field	Enter the expression that defines the condition which governs the validation badge for the current item, namely: Process:AdHocValidationBadgeState.OK() (default value): the Navigation Item state is valid; Process:AdHocValidationBadgeState.NOT_OK(): the Navigation Item state is not valid; Process:AdHocValidationBadgeState.NO_BADGE(): the validation badge is hidden.

Content Validation (Data Logic)

Content validation highlights the violation of predefined rules at content level (missing or unexpected data, wrong data format and so on).

These content violations are shown in three areas:

1. Tab Bar (1) — An icon shows whether there are any issues to be solved in the current page.
2. Content Area (field-level) (2) — An icon and a text message at field-level provide information on how to fix the issue/s affecting such field. Note that there may be two different types of violations, and this may affects the visibility of the error message (as illustrated in Data Gathering ABC / App Task):
   • Mandatory violation: This happens when a Mandatory Fields Data Rule is applied to a Primitive Control or an Expression Rule is applied to a Data Class (see Data Rules Tab). For the end user, this means that these fields are required, and they are marked with an asterisk.
   • Non-mandatory violation: This happens with all other Data Rules. For the end user, this means that these fields are not marked as required.
3. Issue Panel (3) — The Issue Panel under the tab bar can be opened to show a list of all the issues affecting the current page and allows jumping to the issue to be fixed directly.

The content area may show three types, of icons and/ or text messages:

1. Blocking issues — These must be fixed to proceed and end the task. There are two types of blocking issues:
   • Error — Indicates missing essential information or information in the wrong format.
   • Review Request — Data review requests coming from the Data Review App Task (e.g., from a Compliance Officer reviewing customers' data). These are considered blocking issues, as they must be reviewed and closed to proceed. See the Review Request flow in Business Data Comparison ABC / Data Review App Task for more information.
2. Non-blocking issues (Warnings) — These are suggestions on how to improve the quality of entered data. Fixing them is not required to proceed and end the task, but it is recommended.

Configuration

To have content validation rendered in your Data Gathering, you need to perform the following basic steps:

1. Configure a Data Logic Business Object with a set of Data Rules. Data Rules, in fact, prevent content violations in the first place, and determine how content violations are highlighted in the UI in case violations occur.
2. The configured Data Logic BO must then be referenced in the Data tab of your Data Gathering Process Editor.
3. See the table below for full details on Data Rule configuration.

Some Data Rules allow preventing the user from making mistakes in the first place by limiting the end user options. Such Rules should be used as much as possible as they improve efficiency for the end user. Examples of such data Rules are illustrated below:

UI element	Description	Configuration
Option Lists (1)	Option lists allow the end user to select only values contained in a selected catalog (e.g., country, currency). The UI provides a dropdown list/radiobutton list for single objects or a multiple selection field/checkbox list for Indexed Collections.	Option lists are configured through the Catalog Values Data Rule. The Catalog Size property determines the type of option list rendered in the UI. See Catalog Values
Text field (2)	Some fields may provide constraints such as the minimum and maximum size of text or limits on accepted characters.	Text constraints are configured through String Data Rule, which allow defining limitations on a Data Class property of type String (maximum and minimum size, accepted characters, accepted case). See String
Email field (3)	Field that accepts only valid email addresses.	Email constraints are configured through the Email Data Rule, which allows defining additional limitations on a String Data Class property containing an email address. See Email.
Phone Number field (4)	Field that accepts only valid phone numbers	Phone number constraints are configured through the Phone Number Data Rule, which allows defining additional limitations on a String Data Class property containing a phone number. See Phone Number.
Accepted data (5)	Some fields may accept only limited sets of data, e.g., a Document field may only accepts Documents and Evidence.	Data constraints are configured through Eligible Types Data Rules. They define the subset of Data Class types that can be instantiated and stored in a variable, property or collection element of the parent Data Class type. App Tasks use this information to better support the creation of elements inside a collection by proposing to add only allowed values (e.g., A collection of type Person may contain only instances of NaturalPerson and LegalEntity). See Eligible Types.

If content violations cannot be prevented through the use of rules, they can be highlighted in the UI when any configured Data Rule is violated, so that the user can address and correct the issue. Examples of such Data Rules are Single Property Expression, Collection Element Expression, Mandatory Fields

The table below illustrates an example of how each UI element is configured in the case of a Primitive Type with a Mandatory Fields Data Rule:

UI element	Description	Configuration
Mandatory field (1)	Field that is mandatory to be filled (marked with an asterisk).	A Mandatory Fields Data Rule must be added in the Data Logic Editor. Each mandatory item (e.g., Name, Surname...) must be added as a property in the Mandatory Fields section.
Blocking/ Non-blocking issue (2)	Type of violation, either error (marked in red) or warning (marked in yellow)	The Blocking property must be set in the corresponding Data Rule in the Data Logic Rule Editor. If Blocking = true, the issue is blocking (error). If Blocking = false, the issue is non-blocking (warning).
Text message (3)	Text message specified under the field affected by the issue (e.g., This field is required)	The Message property must be filled in the corresponding Data Rule (e.g., in the String Data Rule for string values) in the Data Logic Editor.

Review Mode

As mentioned, validation on Ad-Hoc navigation and on content are separate. However, the Review Mode setting (configured for the Ad-Hoc Sub-Process containing one or more App Tasks) may influences the way both types of validation are displayed in FNZ Studio Runtime. See Review Mode (Ad-Hoc Sub-Process) for full configuration details.

Review ModeOn

Violations are displayed immediately, as soon as the user lands on the page. This is valid both for Ad-Hoc sidebar where validation badges are displayed, as well as for the content area, where violation icons and messages are shown on the page and in the Issue Panel (see Content Validation (Data Logic) for details).

Review Mode Off

Most violations are not displayed when the user lands on the page. This is valid for:

• Ad-Hoc navigation (i.e. no validation badges are displayed)

• Mandatory violations in the content area (i.e. no error messages or icons are displayed)

• Issue panel (i.e. the panel is not displayed unless it contains at least one non-mandatory violation)

However, once the user "visits" the page, validation behaves as follows:

• When the user visits a mandatory field (e.g., clicks and the leaves the field or removes text), a violation icon and message are displayed. The issue panel is also shown.

• When f the user tries to leave the page (e.g., clicks on the Next button), a confirmation modal window warns them that there may be issues.

  If the user decides to stay on the page, all errors are then shown, both at content level (violation icons, messages and issue panel) and at navigation level (Ad-Hoc validation badges).

Review Mode Override

Finally, it is possible to override the Review Mode specified at the level of the Ad-Hoc Sub-Process (as described above) for a specific Data Gathering App Task contained inside the Ad-Hoc Sub-Process itself (e.g., for the Data Gathering App Task in the image below).

This may be useful if a given Data Gathering task needs to have a different review mode with respect to the container Ad-Hoc Sub-Process.

To override the Review Mode for a task, go to its Ad-Hoc tab and:

1. Select the Override Review Modeoption. This will override the review mode option set at the Ad-Hoc Sub-Process level.

2. Select theReview Mode setting in case you want to apply specific Review Mode conditions to this task. Note that this setting is computed only once when the task is initialized.

Collaboration: Comments and Review Requests

Data Gathering allows reviewers to cooperate among them and with editors by highlighting data which needs to be fixed and checked, thus improving efficiency. Collaboration features in Data Gathering include:

1. Comments
2. Review Requests

Comments

Feature Overview

Comments help the collaboration among team members working on the Data Gathering page (e.g. Front Officers). By clicking on the Comment icon above a data field, a user can enter a comment for other team members.

The relevant fields is now marked by a blue dot. The same blue dot is also displayed at the top-right of the page. By clicking on it, the Comments sidebar is opened, and the list of open comments with relevant details is shown. Note that comments are grouped in cards by 'user' (user who entered comment) ans keyboard navigation is supported. Another user can click on each of these comments to be redirected to the field where where the comment was generated. He/she can post a reply on the Comment popup.

Configuration

All configurations relative to Comments are performed in the Collaboration tab of your Data Gathering Process Editor. Note that, as a prerequisite to use Collaboration features, you need to install the WorkspaceCollaboration Extension (see documentation).

Property	Description
Additional Discussion Keys field	You can enter a list of discussion keys. These will be added when creating new Discussions (discussions are containers for the comments on properties/changes). Default value is [].
Enable Comments checkbox	If selected, comments are enabled for each field.
Enable Comment Access Control checkbox	If selected, internal users can specify if a message in a chat or a discussion is visible to a set of external users defined through a Script Function (see property below). Internal users will be able to specify message visibility in the UI through the Visible by Client checkbox in the Business Data Comparison ABC. The list of internal users must be specified through the nm.usermessaging.internalUserRoles configuration property, where you can set a comma-separated list of Roles (e.g. nm.usermessaging.internalUserRoles = Admin, Reviewer).
List of External Users selector	(available if the Enable Comment Access Control checkbox is selected) Select a Script Function that returns the set of external user ids (Indexed String) which are allowed to see visible chat or discussion messages.

Review Requests

Feature Overview

Review Requests simplify cross-team collaboration between data reviewers (e.g. a Risk Officer) and editors (e.g. a Front Officer) working on the Data Review and Data Gathering pages, respectively. Note that pending Review Request in Data Gathering are considered blocking issues, therefore they are shown in the Violation Panel together with all the other issues as mentioned in the Information Framework section above.

Review Requests work as follows:

1. A reviewer (e.g., Risk Officer) revising customers' data on the Data Review page might find some incorrect information and send a review request to an editor (e.g., Front Officer) working on the Data Gathering page.
2. An editor (e.g. Front Officer) working on the Data Gathering page receives the review request in the form of a blocking issue to be fixed in his/her page. The affected field is marked by a blue dot and the request details are visible in the Violation Panel.
3. After fixing the issue/s, the editor can add a comment for the reviewer on the Review Request popup, and then click on the Mark as Resolved button. At this point, the Data Gathering page no longer contains any issues.

Configuration

All configurations relative to Comments are performed in the Collaboration tab of your Data Gathering Process Editor. Note that, as a prerequisite to use Collaboration features, you need to install the WorkspaceCollaboration Extension (see documentation).

Property	Description
Enable Review Requests checkbox	If selected, Review Requests can be entered from the the Data Review App Task.
Review Requests field	This property is used to store all review requests. It must point to a variable of type Indexed DataReview:ReviewRequest.

Developer Toolbar

The Developer Toolbar allows your to access three important developing features:

1. The Theme Editor, which allows editing the look-and-feel of FNZ Studio Runtime. See Theming (Theme Editor).
2. The Inspector tool, which allows navigating to and editing the Business Objects responsible for the FNZ Studio Runtime page. See Inspector.
3. The Integration console, which shows all the integration calls performed by the current Process Instance for easier contextual debugging. The content is a filtered version of the data contained in the Integration Troubleshooting Console available in FNZ Studio (Data & Integration module). See Integration.

You can open the Developer Toolbar from your ABC page by clicking on the arrow on the left-hand side (this is displayed when hovering over the page left border). Note that you need Advanced Studio Permissions to access the tool.

Localization

Language, date and number localization is available for all App Tasks.

As for language, all basic labels used for the Data Gathering App Tasks (e.g., calendar months) are included in the following Platform Packages:

• AppTask (common to all App Tasks)
• DataGathering You can edit the displayed text and add translations through the Overriding Translations for Labels approach (recommended).

As for dates and numbers, App Tasks define their localization according to a Locale configured at FNZ Studio Composition level.

Accessibility

FNZ Studio's Application Business Components (ABCs) have been designed with special attention to accessibility criteria and follow the latest Web Content Accessibility Guidelines (WCAG). All App Tasks have been designed following WCAG 2.1 Success Criteria.

Further Resources

• Avoiding Form Interaction Side Effects in the Data Gathering contains suggestions on how to manage fields that depend on other fields in the Data Gathering.
• Data Logic Business Object contains details information on Data Logic Controls and Data Rules.
• Data Class Business Object