Creating Forms

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:

  • The form contains a section in which the ticket owner is selected. No action is set in the section settings on the right-hand side. In addition, the first section is always visible.
  • The second section does not contain any further fields, but is configured with two things in the settings:
    1. This section is only visible if a ticket owner has been selected in the first section. The condition Ticket owner is not empty is used for this
    2. This section has the action Send ticket and thus allows the form input to be ended.

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.

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:

  • Title: The optional title is displayed at the beginning of a section
  • Section text: The optional section text is displayed directly above the fields of the section.
  • Fields: A list of fields to be filled in the form.

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.

Fields

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.

  • Label: Text that is displayed in front of the field.
  • Show label in form: Whether the label should be displayed in the form. This makes sense for the type Formatted text in particular, as the field then utilizes the entire width of the form.
  • Placeholder: The placeholder is stored in the input fields as a note for this field.
  • Customize default value: This only applies to ticket fields. When active, a designated default value can be set which can be different to the default value in configuration. If not active, then the default value in configuration will apply. Please note that when having a default value in configuration, but not specifying any value for this field in the form (with or without customized default value), then the default value in configuration will apply automatically.
  • Default value: The default value is pre-assigned for this field in this form.
  • Mandatory field: This field must be provided with a value. Please note that ticket fields that are already mandatory fields per Configuration cannot be released from this requirement. Sending a form with a mandatory field will otherwise lead to an error prompt.
  • Hidden: This field is not displayed to the user in the form input. It is therefore used to transmit internal information or can be used for conditions, for example. An example is the subject of the request that is made after submitting the form: with a hidden subject, this can be predefined but not customized by the user filling out the form,
  • Include in the inquiry text when submitting a ticket: For user-defined fields, this controls whether this field should be included in the ticket when the form is submitted. Here too, fields that are only used for additional conditions, for example, do not have to be included in the ticket.
  • Include label: Whether the label should be prepended when adding this field to the inquiry text or if the field's content can use the full width.

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).

Settings

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/Visibility

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.

Action

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.

Preview & Analysis

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.