Convert Forms into Ticket Creation Workflows

[dschipfel]

Current situation

The Forms module is currently primarily used for surveys and collecting feedback. While this is useful, many organizations also use forms to standardize common service requests and automatically route them to the responsible teams.

Suggested improvement

Extend the Forms module to optionally create tickets automatically when a form is submitted.

This would allow organizations to create structured request forms that generate tickets with predefined settings and assignments.

Possible examples:

• Material requests
• Hardware orders
• Software requests
• Access requests
• Change requests
• Service requests
• Onboarding / Offboarding requests
• Facility requests

Possible configuration options

When creating a form:

• Select target ticket type
• Define default priority
• Define default status
• Assign ticket to a specific team
• Assign ticket to a specific analyst
• Map form fields to ticket fields
• Use form answers within the ticket description
• Add tags automatically
• Trigger notifications and workflows

Example

Form: Hardware Request

Fields:

• Requester
• Department
• Device Type
• Business Justification
• Required Date

After submission:

• Ticket is automatically created
• Assigned to the Procurement Team
• Request details are copied into the ticket
• Requester receives confirmation

Similar functionality

A similar concept is available in GLPI, where forms can be used to generate tickets automatically and route them to predefined teams or users. This provides a simple self-service experience for end users while ensuring requests are processed through standardized workflows.

Benefits

• Reduced manual ticket creation
• Standardized request processes
• Improved self-service capabilities
• Better data quality through structured forms
• Automatic routing to responsible teams
• Faster processing of recurring requests
• Reduced workload for service desk agents

For many organizations, forms are not only used for surveys but also as a central entry point for service requests. Allowing forms to create tickets automatically would significantly extend the value of the Forms module and make it a powerful self-service tool.

[edmozley]

Hi @dschipfel

This new feature is coming along nicely - should be able to get it into a release ready for you to use tomorrow (Wednesday)

[edmozley]

The first way of achieving this is to use new workflow triggers and actions

[edmozley]

...and here's what you can now do from within the form - we now have three events - submitted, approved and declined. Each of those events can have one or more (or no) actions assigned to it. This all happens in the "what happens next" tab.

Full write-up coming along with release notes!

[edmozley]

This is built and shipped in 1.3.0. Thank you for the write-up - the worked example and the list of configuration options is what the design got built against, so it is worth saying that up front.

It landed in the Forms module rather than in Workflows. A form now has a What happens next tab beside Fields and Preview, with three sections: when the form is submitted, when a request is approved, and when one is rejected. Each holds as many actions as you want, in the order you choose. Raise a ticket, send an email, call a webhook, create a task, add a note.

Underneath it is the existing workflow engine rather than a second one, so a form's automation shows in the same run log as everything else, and it behaves the same whether the form was filled in on the portal, by an analyst, or through the REST API.

Against your list, honestly:

• Select target ticket type - yes
• Define default priority - yes
• Assign to a specific analyst - yes
• Use form answers within the ticket description - yes. Leaving the body blank gives you every answer as a table; or write your own and drop answers in by field label, e.g. {{submission.fields.Device Type}}
• Trigger notifications and workflows - yes, via the email and webhook actions, and form.submitted still fires so any existing workflow keeps working
• Define default status - not yet
• Assign to a specific team - not yet, only to an individual analyst
• Add tags automatically - not yet

Those last three are real gaps rather than decisions, and they are the next thing I would add to this.

Your Hardware Request example works today except for the team assignment - you would route it to a named person rather than to Procurement as a queue. The confirmation email does work: actions can now use what an earlier one produced, so "raise a ticket, then email the requester their ticket number" is a single rule using {{last.ticket_id}}. That pairing was not possible before this release in one rule or in two.

One thing worth flagging if you use catalogue approvals. Three faults turned up while building this, all of which failed silently:

• Editing an approval-gated form was quietly removing the approval requirement and its named approver, so requests stopped needing sign-off and stopped becoming tickets
• The three approval events were being announced but could never be listened for, so an approver was never told a request was waiting
• A rule could not be restricted to a single form, so the only rule you could save ran for every form on the system

All three are fixed, but the first one is not retrospectively repairable. If you have approval-gated forms that were edited into a new version, please check they still name their approver.

Documentation:

• Forms - the module, including the new tab
• What happens next - developer guide - the full write-up: storage, execution, how it wires into both modules, with code
• Workflows - the engine, its triggers and merge codes
• Release notes

There is in-app help too, under the guide link in both Forms and Workflows.

Upgrading needs System - Database Verification run once; it adds a single column. Existing forms behave exactly as they did until you open the new tab, so nothing changes by itself.