A form consists of sections in which the fillable fields are located. These sections are defined in the design view and fields are assigned to them. The use of multiple sections is not absolutely necessary for a simple form. These are mainly needed if the form is to be sent based on certain entries or if you want to map extended use cases with different question/answer paths in the form.
Below, you can see a basic form that only allows the ticket owner to be selected. Sending is only possible once the owner has been selected.
To familiarize you with this form, here is the explanation:
Note: The name of the form is assigned in the settings. This name is only used for structuring in the Configuration application and is not displayed to users when the form is executed. To display a title to users, only the optional title is used in the design view above the sections.
The primary task of the sections is to show and hide certain field groups. When submitting the form, only fields from sections that are visible are transmitted. A section consists of:
Note: It is also possible to use only the title or the section text in a section without fields, e.g. to provide notes. Conversely, of course, only fields are permitted in a section.
Note: A section completely without fields and optional text can be used for submitting the form. This can be achieved by defining such a section at the very end of the list, for example. In combination with conditions, it can be achieved that the form can only be sent if certain entries have been made.
All defined ticket fields are available for adding fields. This includes both the standard fields and user-defined fields from the Configuration. In addition, new fields can be defined specifically for the form. Various field types are available here.
Filled ticket fields are automatically applied to the new ticket when the form is sent, while additionally defined fields can be used in the request text of the ticket.
Note: The same ticket field can be used in several sections, but must not appear twice in the same section. When using a ticket field more than once, all occurrences will have the same value. However a different default value can be set for each field, which will be applied when the section becomes visible. Custom fields on the other hand are always distinct fields even if a field is duplicated and/or has the same label.
Note: The global mandatory field rules cannot be bypassed. If, for example, the category is mandatory but should not be queried by the form, the category can be assigned using a hidden field.
Note: The ticket field Ticketowner requires special handling for data protection reasons. It cannot be used in forms that are located in public folders. If the configuration changes so that the form is located in a public folder, the form can no longer be executed and displays an error in the configuration. If the form is executed by an enduser, the ticket owner field is automatically deactivated and always sets the enduser as the selected ticket owner (any default value set is ignored).
The settings on the right-hand side of the dialog are also divided into sections. This means that you can work on different properties in the design and in the settings at the same time and, for example, work on a property that is significantly higher or lower in the list than in the design view. The settings also remain in place during the Preview and can be changed dynamically. You can then immediately see the effect in the final form.
Conditions can be defined for each section as to when this section becomes visible. For example, the selection of a specific value of a field is necessary for fields based on it to be displayed.
The available operators vary depending on the data type of the selected field. The field of a condition must be contained in a previous section so that it can be referenced. Conditions can be composed in a variety of ways as AND- and OR conditions. The preview can be used to check whether the conditions for individual sections work correctly.
Note: In order to reference a ticket field as a condition that is actually only to be set at a later point in time, this field can be hidden in a previous section. Since the ticket fields are unique based on their keys, they always contain the same content. This is not possible with user-defined fields.
Sending the form is available as a section action. By submitting the form, a new ticket is created. Sections that define submitting as an action are marked with a target flag. Optionally, a confirmation text can be set, which is displayed to the user when the form is sent.
Note: If a section offers submit as an action and is also displayed in the form, all subsequent sections are hidden and not executed.
Note: Several sections can also be set as the end section, as long as only one of them is visible via the condition. This allows different paths to be displayed in the form.
The form can be displayed with the preview as it would look when actually executed. Sample values can be entered to test the form and, in particular, the display and hiding of the sections.
In addition, a section overview is displayed for analysis, in which you can see which sections are shown. Here you can also see the reason why sections may not be displayed.
Note: When you click on Submit, no ticket is created, but all mandatory fields of the form are checked. However, no global rules for ticket creation stored outside the form can be checked. If, for example, an end user is required to enter a category in INETAPP - mandatory field globally in INETAPP, but the category is not a mandatory field in the form, then no error will be displayed in the preview if it is missing for sending. In the actual execution, an end user will receive the error message for the missing identifier.