Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Configuration of items

Updated on May 25, 2021

You can configure items in a very similar manner to item groups, but items have their own specific pieces of configuration. The system presents a modal dialogue to facilitate the configuration.

The following elements need to be configured when creating a new item:

Item/group #
The number of the selected item within the KYC Type. It is presented in read-only and the user cannot change it.
Item property

This field references the response properties that define the data to be displayed and captured at run time. To define a response property, carry out one of the following tasks:

  • Use the autocomplete control to locate and select a readily available properties created in the prior steps.
  • If the property does not exist in the system, create a new one by clicking on the magnifying glass icon to open and define the new property.

Depending on the type of property, the item will be classified as simple (scalar properties) or complex (page and page-list properties), a classification that introduces some variances in behavior.

Item properties must reside in the hierarchy under the same class than the KYC type that is being edited or under one of its parent classes. It is important to keep the reuse of item properties under consideration and create and move them as required to maximize reuse.

A very important aspect in creating properties for simple items is the configuration of the associated UI control. By default, the KYC engine uses that configuration to display and capture the item in the screen. For example, if you want to create an item and capture it using a text area control, the item property created for that item should be configured to use the TextArea control.

Display and Edit section
While the capture of simple items is done as described above by using the UI control associated to the item property, the capture of complex items and of simple items with special needs is done through ad-hoc sections created for that purpose. Use the open rule control to select the section in your class hierarchy that will manage the display and capture of your item.
Is Complete Condition
The system can easily determine whether a simple item is complete or not by just checking if the associate property has a value. However, it cannot do it without additional configuration for complex items. The Is Complete Condition allows you to specify the when rule that will determine whether a complex item is complete or not. For example, in a complex item created to support an address with multiple fields (for example, address lines, city, postal code, country, and so on), the Is Complete when rule could check for the presence of the very minimum data to consider the address complete (for example, address line 1 and postal code).
Item Text
Internal name given to the question and used to identify the question within the KYC Type in design time. This text is not displayed to users in run time.
Text display type
Text that contains the wording of the question and that is presented to users in run time. For simple display text, select Field Value and then click the open rule icon to create a new rule or edit an existing one. For displaying text that requires complex formatting (for example, guidance links or italic fonts), select Paragraph Rule. In the autocomplete field, select an existing paragraph rule, or enter a new rule name and then click open rule icon to open or create the paragraph rule.
Profile association type and associated Profile(s)
This option can be used to display the item based on the active due diligence profile. The profiles association type can be inclusion, exclusion, or show all. If the association type is inclusion, the item will be displayed when the selected profiles are active. If it is exclusion, the item will be hidden for the selected profiles. If it is show all, the item will be visible regardless of the active profiles.
Display condition

In addition to the use profiles, the visibility of an item can be driven by a display condition. When rules, map values, decision trees, and decision table are available for use. Use the autocomplete control to select an existing decision rule or enter a new rule name and click Edit to create. If no decision rule is configured, the item is displayed by default.

It is important to note that the system uses this configuration in combination with profile association. The item will be visible when both configurations, profiles and display conditions, allow visibility. If any of the two determines that the group should not be visible, the group will not be displayed.

Initiate Type Re-Evaluation
When this checkbox is selected, the system automatically triggers the process that re-evaluates the applicability of KYC Types on the case. When conditions are met, other KYC Types can be added to the case and made ready for data collection.
Initiate Profile Re-Evaluation
When this checkbox is selected, the system automatically triggers the processing required to re-evaluate the active profile. If the profile is updated, the KYC Type is refreshed to display the items or item groups to be displayed or hidden.
Required condition

Use to drive the mandatory condition of the item. If a decision rule is associated and it returns true in run time, the item is considered mandatory and denoted with the default icon. If there is no rule configured or the rule returns false, the item will be considered optional.

This attribute works only for simple items. Complex items require mandatory conditions to be configured within the edit section attribute associated with it (see above Item property and Display and Edit section).

Read Only Condition

This configuration enables the control using decision rules of the edit permissions on the item. If a decision rule is associated to the item and it returns true in run time, the item is presented in read-only. Otherwise, the item is in read-write mode.

It is important to note that other factors can also drive the read-only condition of an item. For example, when a KYC Type is displayed for review in a maker-checker process, all items in the KYC Type are presented in read-only. Another mechanism to control this condition is by setting procedurally the property IsReadOnly from one of the data-transforms used by the engine (for example, initialization data transform).

Supporting evidence
This configuration enables the capture of supporting evidence for the item (see Supporting Evidence). When configured, the item is presented in the screen along with a link that let users select supporting evidence from various sources (for example, attachments, requirements). In design time, select the KYC Supporting Evidence rule that enables the appropriate sources and the decision rule that will determine when to make the option appear. The list of KYC Supporting Evidence rules available out-of-the-box are:
  • CustomerDocuments: users can select documents already associated to the customer, either because they were uploaded manually to the current case or earlier in previous journeys.
  • CustomerRequirements: users can select Requirements cases that could have been completed for the party undergoing due diligence (contracting party or related party).
  • CustomerDocumentsAndRequirements: users can select documents, requirements, or both as the supporting evidence for the item.
On-Change launch data transform
When a data transform rule is referenced in this field, any on-change event of the property associated to the item will result in the automatic execution of the data transform. This will happen, for example, when the user clicks or tabs away from the UI control setup in charge of the capture of the item. This data transform can be used for different purposes like, for example, trigger a re-evaluation of the customer risk or automatically populate the answer to other questions.
On-Change transition data transform
Similarly to the on-change launch data transform, the configure data transform configured will be triggered on-change of the property associate to the item. However, in this case, the logic waits until the engine has re-evaluated all the other items in the questionnaire before it is executed. That way, the logic has access to the final snapshot of the KYC Type before taking any further action. This approach can bring some advantages in certain specific business scenarios, as well as a performance overhead if further changes are required after the initial evaluation (a second execution of the re-evaluate logic). You should carefully consider the use of these data transforms and use them only when required.
Audit note
The audit information provided here will be used to keep track of changes across different versions of the KYC Type. It is only used in design time and has no impact in run time.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us