Applies to version: 2020.1.x and above; author: Adrian Baszak
- Refreshing the default values
- Configuration of default value in the picker fields
- Setting the default value on the selected step
- Using the form rules
- Setting the default value via choice field
- Good practices – efficiency and maintenance
Setting up default values in form fields is one of the most basic and easy things that we can do to facilitate and improve the user experience of working with forms in the WEBCON BPS system. The following article describes the various methods used to configure the default values and examples of use.
In WEBCON BPS Designer Studio, the options related to default values are available in the form field configuration in the “General” tab.
Fig.1. Configuration of the default value settings
For each type of form field (except for charts and data table and rows), you can define the default value. You can use the values of other form fields, business rules, context variables, fixed values and data sources in the configuration. Setting the default value of the form field will take place:
- At the first step, where the form field is visible (this also applies to technical form fields)
- Only when the form field had no value before
- Always when loading the form in edit mode (the default value is set regardless of whether the form field is editable or read-only)
- After changing the form field value, if the form field was properly configured (more on this later)
The rest of the article also describes how to set the default value by using the form fields and picker fields.
There are cases when the default value of the form field depends on the value of another form field and both are meant to filled out on the same step. In this situation, the default value cannot be set when the form is first loaded. To set the default value after completing another form field:
a) Check the “Set when refreshing default values” option – the default value will be set when another form field will force the default values to be refreshed
b) On the dependent form field you must check the “Value will cause default values to be refreshed” option – when this option is enabled that after changing the form field value:
- All rules defined in the “Requiredness restriction” section will be activated again
- The default value will be recalculated for all form fields with the “Set when refreshing default values” option enabled
An example configuration will be presented in the next chapter.
The default value in the picker fields should be set in the ID#Name format where “ID” and “Name” are compatible with the configuration of the choice field. This format is used for simple dictionaries (e.g. currency or bank account number form field). The value set in this way is not checked in the data source – the form is loaded quicker, but on the other hand it is possible to set a value that does not belong to the data source. Also, if the choice field sets other fields – the data source will be searched to download appropriate values.
You can set the value by specifying the ID that uniquely identifies the row/entry from the data source. To correctly complete the choice field, the given value must be found in one of the data source columns (those for which the search option was selected in the advanced configuration of the form field).
Fig. 2. Configuration of searching in the choice field. If the default value will not be set in the ID#Name format – the value will be searched in the WDF_ID, Name and externalID columns
This approach, unlike to the previous one, will always search the data source. The more column will be searched, the greater will be the impact on form loading time. Using only the identifier allows to enter the value other than the choice field ID – e.g. NIP or vendor ID from an external system. It is also insensitive to display name changes or name format required for fields that support multilingual names.
The default value should not be set by specifying the display name or their fragment. It can cause incorrect matching of values in the data source, if this value matches more than one record in the dictionary.
Fig. 3. An example of correct and incorrect configuration of the default value
If the default value is to be set only at the selected step (instead of first one where the form field will be visible), add the appropriate condition in the rule (it is recommended for facilitating and maintaining the configuration) or break inheritance of the form field configuration in the form settings on the selected step.
Fig. 5. Configuration of the default value set on the selected step via break inheritance of the form field configuration
To set the default value, you can also use the form rules related to the change of the form field value. This solution is useful when the form fields are dynamically hidden or shown, or when the default value is to be refreshed when the value of the form field is changed.
The default value of form field can also be set after selecting the value in the choice field. Values from the selected columns can be mapped to the form fields.
To optimize the work of the form fields (e.g. quick time of page loading) and to facilitate maintenance of correct configuration:
a) Minimize the number of the form fields whose value change refreshes the default values
b) Minimize the number of form fields whose default value is set after changing the values of another form fields
c) Minimize the number of default values downloaded from data sources:
- If several default values are from the same source, the good solution might be prepared a choice field that will automatically fill the related form fields via it’s advanced configuration
d) In some cases, the setting of the default values can be replaced by actions set to trigger on a path if:
- The values are downloaded by using network services (web services)
- The default values are not necessary for a person who is currently performing a task
- The default values require a significant number of operations and they are related to each other (e.g. calculating a business trip)
This chapter describes the different methods to set the default value by using a simple cost invoice form.
Fig. 6. An example of form with the default values
- Created by and Created date – this form fields are set with default values. “Created by” is currently log in user and “Create date” is current date. The default value is filled in even though the fields are read-only.
Fig. 7. Configuration of the default value of the “Created by” and “Created date” form fields
- Invoice type – this form field is a choice field with the ability to enter multilingual names. The default value is set by providing an ID to correctly save the name translations. ID is stored in a process constant which allows you to enter the different values depending on the DEV-TEST-PROD environment, and use them in other places in the process configuration.
Fig. 8. The default value of the “Invoice type” form field
- Invoice number – this form field has no default value, it is completed manually by the registering user
- Invoice date – this form field has no default value, it is completed manually by the registering user. However, it impacts the setting of the default value in the “Payment date” form field so the “ Set when refreshing default values” option is checked.
Fig. 9. The configuration of refreshing the default values by changing the value in the “Invoice date” form field
- Currency – this form field is the choice field whose default value depends on the related business entity. The suggested value can be changed by the registering user. The default value for this field is provided in the ID#Name format
Fig. 10. The default value in the “Currency” form field
- Net amount and Gross amount – these form fields have no default value, it is completed manually by the registering user.
- Payment date – is a date field whose default value is “Invoice date + 30 days”. The suggested value can be changed by the registering user. When the form is loading – the “Invoice date” form field is empty, so the “Payment date” default value must be set when refreshing the defaults.
Fig. 11. Configuration of the default value of the “Payment date” field
It is important that the default value will only be completed if “Payment date” is empty. To complete the default value whenever you change the “Invoice date” value, you must add the form rule to change the form field value instead of the above configuration.
Fig. 12. Configuration of the default value of the “Payment date” field by using the form rule on the “Invoice date” value change
- Supplier Name – this form field has no default value, it is completed manually by the registering user. However, it impacts the setting of the default value in the “Bank account number” form field, so that the “Set when refreshing default values” option is checked. Also, after selecting the value, the fields with detailed information about the vendor are completed.
Fig. 13. Advanced configuration of the “Supplier name” field. Values from the data source column (Source column) will be entered to the appropriate form fields (Target fields)
In order for the default value in the “Bank account number” field to change after selecting the vendor, the form rule has been configured to change the value in the “Supplier Name” field, which will remove the current value from the “Bank account number” field.
- Supplier ID, City, State, Zip Code – this form fields has no default values, they are completed automatically after selecting the value in the “Supplier name” field and cannot be changed by the registering user.
- Bank account number – the default value of this field depends on the value in the “Supplier Name” field, so the option to refresh default values is selected. Also, the default value is set in the ID#Name format, because it is downloaded from the same dictionary that is the data source of the choice field.
Fig. 15. Configuration of the default value in the “Bank account number” field
There are a lot methods for setting the default values of form fields and each of them has its use in different scenarios. When used correctly, default values can make the form user-friendly by reducing the number of inputs a user must provide and making their work as straightforward as possible. However, its is important to remember that the configuration under the hood should also be kept as simple and efficient as possible, so that it is easier to reconfigure in the future and so that it does not negatively impact loading times.