Ticket forms

Administrators manage custom customer forms and public web forms.

Overview

This page explains how to use Ticket forms and describes its main effects. Test changes in a test environment first whenever they may affect existing tickets, permissions, notifications, or automations.

Typical workflow

  1. Create and edit a form. Open the relevant administration or action form, enter the required values, and save only after checking assignments and required fields.

  2. Activate, deactivate, or delete a form. First check which existing records or users are affected. Where possible, deactivate entries instead of deleting them permanently.

  3. Create, edit, and deactivate form fields. Open the relevant administration or action form, enter the required values, and save only after checking assignments and required fields.

  4. Configure customer assignments and visibility. Perform the function in the designated form and immediately verify the result in the corresponding overview or on the affected ticket.

  5. Set the public URL identifier. Open the existing record, change only the required fields, and check dependent assignments before saving.

  6. Take rate limits and snapshots into account. Perform the function in the designated form and immediately verify the result in the corresponding overview or on the affected ticket.

Notes

  • Visible menu items and actions depend on the signed-in agent’s group and program permissions.

  • Deactivated entries are often retained for existing tickets and reports, but are no longer available for new assignments.

  • After making changes, test at least one realistic use case with a user in the affected role.

Forms overview Customer portal form

Standard tickets alongside customer forms

Standard ticket in addition to forms keeps standard ticket creation available even when custom customer forms are offered. Without this additional option, the available forms determine the offered creation workflow. Check the result as a signed-in contact who has access to a custom form.

Automatic process startup and multiple attachments

Forms can accept multiple files and optionally start an active KimProcesses template after ticket creation. The selector appears only when the add-on is available and enabled. A process-start failure does not remove the ticket; an internal note contains the error.

Configuration is explained in Start processes after a form submission.