1) What is your original issue/pain point you want to solve?
Zammad’s built-in feedback form is a single fixed form; there is no way to build custom, multi-step intake forms.
2) Which are one or two concrete situations where this problem hurts the most?
Public-facing intake channels need tailored forms per channel/context — category-specific questions, an anonymity option, and offline capability on mobile devices in the field.
3) Why is it not solvable with the Zammad standard?
The form channel is a single fixed form and is not extensible.
4) What is your expectation/what do you want to achieve?
A form builder for custom (public) forms, delivered as a progressive web app, feeding submissions into tickets.
This would be a fantastic addition to help curate and qualify customer requests before the ticket is even created, significantly reducing back-and-forth and unqualified tickets.
Building on the original idea, here are a few key elements that would make a Custom Form Builder truly powerful for Zammad:
1. Independent Fields & Conditional Logic
To maintain complete freedom in designing forms, form fields (like dropdowns or Yes/No toggles) should not strictly require linking to an existing Zammad ticket attribute.
Decision Trees: We could build step-by-step logic based on isolated questions. For example, selecting option “A” triggers a specific set of follow-up questions, while selecting “B” displays a text block containing links to Knowledge Base articles or external URLs to deflect the request.
Cleaner Database: This prevents cluttering the Zammad database with dozens of highly specific custom attributes that are only used to route one particular intake form.
2. Custom Payload Templating
Instead of mapping every form field to a ticket column, the system could compile the submitted answers into a structured text block for the first ticket article.
Administrators could use a template editor (similar to the existing email notification triggers) using variables like #{form.device_type} or #{form.issue_description}.
Agents would receive a perfectly formatted initial request containing only the relevant information gathered during the user’s specific path in the decision tree.
3. Frictionless Access & Optional Validation
The forms need to adapt to different support contexts:
Public & Internal Access: Forms should be accessible via a direct web link without requiring prior login to avoid unnecessary friction, while also remaining natively accessible from within the Zammad interface for already authenticated users.
Optional Email Gatekeeping: For public forms, an email field must be required. As an advanced setting, administrators should have the option to reject submissions if the provided email address does not belong to an existing Zammad user (acting as a strict filter for dedicated support channels).
By implementing these features, we could proactively guide users, deflect easily solvable issues with targeted links, and ensure that when a ticket is created, it is fully qualified.