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

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.

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.

  • Form URL: The URL and a copy button to share the form URL.
  • Show on Start Page: Check, to display it on the front page of the server.
  • Link Name: The name of the form, when displayed on the front page.
  • Link Description: A longer description text that is displayed in addition to the name.
  • Use Form Logo: A checkbox, that is displayed if a logo is set. If checked, the logo will be used for the front page as well.

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

Conditions on fields of the ticket

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.

Action

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:

  • If Apply form is selected, only one editing step is created in the ticket. Otherwise, two steps are created.
  • The permissions required to execute the actions are ignored when the form is submitted.
  • The status of the underlying ticket is taken into account, e.g. a closed ticket can not be authorized.
  • The Rate ticket action can be applied to both open and closed tickets.
  • If the action can only be executed under certain conditions, this requirement must also be fulfilled by the form, e.g. if the action requires text, at least one form field must be included in the editing step. If a resource is required, e.g. for Forward or Authorize, a resource must be supplied, at least as a hidden field.

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.

Preview & Analysis

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.