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 a user who cannot list users (permission List users and groups is missing), then the ticket owner field is automatically deactivated and always sets the current user as the selected ticket owner. (Any default value set is applied. Forms which modify tickets will have the current ticket owner preselected.)
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.
Forms that create new Tickets display additional options, so that the link to the form can be copied, and the form could be added to the start page of the server.
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 various ways as AND- and OR conditions. The preview can be used to check whether the conditions for individual sections work correctly.
Note: For fields of type Attachments
it uses the number of uploaded attachments for the condition.
Note: To reference a ticket field as a condition that is being set at a later step, 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.
Forms that modify an existing ticket can also define conditions that refer to the underlying ticket. To achieve this, a ticket field, recognizable by the ticket icon, must be selected for the condition. The condition refers exclusively to the value in the ticket, not to the value in the form if the same ticket field is used.
Depending on the status and settings of the ticket in the form, this type of condition makes it possible to query other data or to prevent the form from being executed, for example by only displaying a section with a message.
An action allows the form to be sent, i.e. the Send
button is made available. Depending on the form, a new ticket is created, or an existing ticket is modified. Sections with an action are marked with a target flag. Optionally, a confirmation text can be set, which is displayed to the user after submitting.
If the form modifies tickets, a ticket action can be selected that is executed on the ticket. The following rules apply:
Apply form
is selected, only one editing step is created in the ticket. Otherwise, two steps are created.Rate ticket
action can be applied to both open and closed tickets.Note: If a section contains an action and is displayed in the form, all subsequent sections are hidden and do not need to be filled in.
Note: Multiple sections can be set as the end section as long as only one is visible using the condition. This allows different paths to be displayed in the form.
The form can be displayed with the preview as it would look during actual execution. Exemplary values can be entered in order to test the form and, above all, the display and hiding of the sections.
If the form modifies existiung tickets and conditions are defined for fields of the underlying ticket, an additional section appears in the upper area. Here, the current values of the underlying ticket can be simulated and the conditions of the form can be tested.
In addition, a section overview is displayed for analysis, which shows which sections are displayed. 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 obliged to enter an ID (Kennung
) in INETAPP - mandatory field globally in INETAPP, but the ID is not a mandatory field in the form, then no error will be displayed in the preview if the ID is missing for sending. In the actual execution, an end user will receive the error message for the missing identifier.