When you do the same kind of action repeatedly — request approval, escalate to vendor, document an incident — your admin can wire that up as a form. Fill it out once on a ticket and the right thing happens consistently.

Forms

Problem: Some actions on a ticket need the same information captured the same way every time — "request approval to spend over $500", "escalate to vendor", "send to manager for review", "document a security incident". Without a standard way to capture that info, agents free-text it into notes, approvers don't know where to look, and the trigger that should follow (sending an email, creating a sub-ticket, kicking off a workflow) doesn't happen.

Horizon's answer: Custom forms. Your admin defines a reusable form for each repeatable action — fields, validation, what triggers when it's submitted. You fill out the form in the context of a specific ticket. The data gets attached to the ticket, and if the form is wired to a workflow, that workflow fires.

Where forms come from

Forms are created by your admin in the Horizon admin panel. Each form has:

• A name (e.g. "Request Manager Approval", "Vendor Escalation").
• A set of fields. Field types include text, number, toggle (yes/no), dropdown, user picker, textarea, date, and datetime.
• Optional validation rules per field.
• Optionally: a workflow that fires when the form is submitted.

You don't create or modify forms — that's an admin task. You consume them.

Submit a form on a ticket

1. Open the ticket in your helpdesk.
2. In the Rocketship ticket widget, click Submit Custom Form.
3. Pick the form you want to submit from the dropdown (if your account has multiple).
4. Fill in the fields.
5. Click submit.

If the form has a workflow attached, it fires immediately — and depending on what the workflow does, you may see a notification, a new todo, a reassignment, or nothing visible (if the workflow runs silently).

What gets recorded

Each submission is saved against the ticket. Anyone reviewing the ticket later can see:

• Which form was submitted
• Who submitted it
• When
• All the field values

This is the part that makes forms more useful than internal notes — the data is structured, queryable, and tied to a specific action.

When to use a form vs. a note

Common errors

• "Form validation failed" — one or more fields didn't pass the validation rules your admin configured. The error message lists which field(s) — fix and resubmit.
• "Missing form_id" — the form selection got lost. Refresh the page and try again.
• "No forms configured" — your admin hasn't created any custom forms yet. If you think one should exist for an action you do regularly, ask them.

Tip: If you find yourself writing the same internal note over and over for the same kind of action — "FYI escalating to vendor X for reason Y", "approved by manager M" — that's a strong signal a form should exist for that action. Bring it up with your admin. Replacing five free-text notes per week with a one-click form pays for itself fast.