For the complete documentation index, see llms.txt. This page is also available as Markdown.

Form properties

Tab Properties allows configuration of parameters related to the behavior, appearance, and interaction of the form during runtime. These parameters affect how the form is presented to the user, how it communicates with services, and which interface elements are visible. Properties are grouped into thematic sections.

Figure 1. Appearance of the "Properties" tab

Section "General"

Application description

A text field that allows you to add a short description or comment to the form project. This description is not shown to the end user, but it helps with identification in the repository and in team work.

Entry services

This section contains a list of services that are attached to the application as startup services. These services will start at the beginning of the application's lifetime, if the activity condition is met. Entry services are executed sequentially, according to the order on the list. In edit mode, it is possible to add and remove an entry service and define the service launch condition.

Figure 2. Section "Entry services" with added services

Services mapping input parameters

Availability of functionality depends on the license and may not be available in all deployments.

A section Services mapping input parameters allows you to connect services whose task is to supply form fields with data before it is started. These services are launched automatically when entering the application - both during standard opening of the form and in the case of its unparking (session resumption).

Thanks to these services, for example, you can pass customer data from an external system, set initial field values, or open the application on a specific page.

Characteristics of mapping services

  • do not have output parameters,

  • the result of the service's operation is directly mapped to form fields or session variables,

  • may specify the page on which the form should open,

  • run always first - even before entry services.

Implementation example (ServiceProxy)

To populate a field, the service should return in the map a key that will have the field identifier on the application and a value that will be assigned to it. Do not define outputFields for fields returned from the callService() method. To open the application on a specific page, pass the variable recentlyRequestedPageMid to the output map and pass the mid of the appropriate page to it.

Demo application: demoSerwisMapujacyParametryWejscia

Exit services

This section contains a list of services that are attached to the application as end services. These services will start before the end of the application's lifetime, if the activity condition is met.

Statistics

This section contains options related to collecting statistics from the application. For each application, it is possible to specify which statistics should be collected and how often.

External statistics

Additionally, in the Statistics section, you can enable sending Google Tag Manager statistics. Read about the functionality itself in the GTM documentation: GTM statistics.

Section "Appearance"

This section is responsible for configuring interface elements visible while filling out the application.

Side and bottom panel

Availability of functionality depends on the license and may not be available in all deployments.

Allows you to enable or disable the visibility of additional panels (e.g. a side menu with information, notifications, or content blocks). Panels can be used to display useful links or cross-sell elements.

Artifacts of type Content (TextContent), selected from the repository. Editing the panel (adding a visibility condition, listeners, styles, or selecting a slot) requires clicking the pencil icon, and saving the changes requires clicking the save symbol. The placement of the added content is determined by the option Slot. Panels allow you to define multiple pieces of content that will be displayed one below the other.

Figure 3. Side and bottom panel - example of content definition
Figure 4. Sample appearance of the side panel on the application

The content of the bottom panel is determined by setting the Slot option to the appropriate value, which depends on the implementation.

Figure 5. Sample appearance of the bottom panel on the application

Visibility of steps

Controls the display of the top horizontal progress bar (the so-called form steps). Its hiding can be used in single-page applications or simplified processes.

In this section, you can define the visibility condition of the steps bar and indicate the elements that trigger this change (the so-called listening to elements).

Figure 6. Example of a defined condition visibility of the steps bar
Figure 7. Example of steps on the application

Visibility of the navigation bar/button

Visibility of the navigation bar allows you to determine whether the bottom navigation bar (with Back/Next/Submit buttons) should be visible. In the section Visibility of the navigation button only the condition for displaying the Next/Submit button is specified. In both sections, remember to indicate the elements that trigger the change (the so-called listening).

Figure 8. A section "Visibility of the navigation button"

Visibility of additional header element

Availability of functionality depends on the license and may not be available in all deployments.

Allows displaying an additional element in the first position of the page header (e.g. an icon, a button triggering an action). The type of element displayed may vary depending on the implementation and its presence is not guaranteed in all implementations.

Bottom Bar

Availability of functionality depends on the license and may not be available in all deployments.

Determines whether the form footer should be shown to the user. It can be hidden conditionally - e.g. on information or summary pages.

Panic Button (FAB)

Availability of functionality depends on the license and may not be available in all deployments.

Determines whether the floating button on the application page, opening an additional window (FAB - Floating Action Button) should be visible on the form.

Visibility

The button visibility is set in the subsection Visibility, where you specify the condition for showing the button and the element that should trigger this change (listening). This allows the button to be visible only in certain situations, e.g. after checking a box or in a given step of the application.

Masking phone number

In the section Masking you can define whether the phone number in the button popup should be masked (e.g. partially hidden). The number's visibility is determined by a condition and listening to the element triggering the change.

Additional settings

In the subsection Additional data you can indicate form components whose values will be passed to the button configuration - phone number, id or configuration version. This option is available only in selected implementations.

Figure 9. Visibility of the "Panic Button" section with set conditions and parameters

Technical configuration

The size and position of the browser window, as well as the website address it leads to, are defined for a given installation in the webforms.xml configuration file. Example values:

Configuration parameters:

  • windowPositionX – distance of the window from the left edge (px)

  • windowPositionY – distance of the window from the top (px)

  • windowSizeX – window width (px)

  • windowSizeY – window height (px)

  • actionLink – website address opened in a new window; it can contain form variables available when the application starts, e.g.:

Translations and text keys

The labels on the component can be customized by adding translations in the main form template:

Translation key
Description
Default content

iew.fab.need.help

title in the startup popup

“Need help?”

iew.fab.well.call.up

description in the startup popup

“We will call you back as soon as possible…”

iew.fab.order.call

button text in the startup popup

“Order contact”

iew.fab.thank.you.title

title in the thank-you popup

“We will call you back soon”

iew.fab.thank.you.desc

description in the thank-you popup

""

iew.fab.error.could.not.order.conversation.title

title in the error popup

“Failed to order a call”

iew.fab.error.try.again.desc

description in the error popup

“Try again in a moment”

Demo applications: demoFab, demoFabZmienioneLitera

Loading progress style

Defines how the loading indicator is displayed during form initialization. The default value is "preloader". Available styles may vary depending on the theme (e.g. progress bar, spinner, logo animation).

Conditional application titles

Allows you to define different titles displayed in the form header depending on whether specified conditions are met. Each title has an assigned visibility condition (e.g. data-dependent), which allows the header to change dynamically depending on the application stage or the user's role.

Title definitions

Each title definition is presented in a separate table row. The given row contains:

  • Title key – translation identifier or fixed text displayed in the form header,

  • Visibility condition – logical expression that specifies when the title should be used,

  • Change-triggering elements (listeners) – list of components or variables (separated by commas) whose change causes the condition to be re-evaluated,

  • Edit and delete buttons – allow you to modify or delete the title definition row,

  • Save button – visible while editing the row; saves the entered changes,

  • Reorder handle – allows you to drag the title and set its priority (order of condition checking).

Rows are processed from top to bottom, so if several conditions are met, the title from the topmost row will be displayed.

Figure 10. Example of four defined conditional titles

Demo application: demoFormTitles

Demo application: demoWlasciwosciSzablonuWniosku

Last updated

Was this helpful?