Can a GitHub Issue Form Require a Support Ticket ID Before It's Accepted?
Yes, with a catch. GitHub's issue forms support an input field with validations: required: true, so you can add a "Support ticket ID" box that blocks submission until something is typed into it. What you can't do natively is validate what gets typed. GitHub's schema for issue forms has no regex, pattern, or lookup attribute for input fields. Required means non-empty, and nothing more.
That gap matters more than it sounds like it should, because "required" is exactly the word that makes teams assume the field is doing more work than it is. A required field stops a blank submission. It does not stop N/A, a Salesforce opportunity number typed into the wrong box, or a real ticket ID that was accurate on the day the issue was filed and has been wrong ever since the ticket got merged into another one.
What the required field actually enforces
Set up as a standard .github/ISSUE_TEMPLATE/bug-report.yml form, the field looks like this:
- type: input
id: ticket-id
attributes:
label: Support ticket ID
description: The Zendesk ticket number for this issue, if one exists
validations:
required: trueThat configuration guarantees a reporter cannot submit the form with the ticket-ID box empty. It's a real constraint and worth having; a mandatory field trains people to look for the ticket number before they file, and a fair number will actually go find it. But the validation stops at "is there a string here." GitHub doesn't check the string against a format, doesn't call out to Zendesk or Intercom to confirm the ticket exists, and doesn't do anything when that ticket later gets closed, merged, or reassigned to a different account. The issue forms syntax reference documents required as the only validation keyword available on input and textarea fields. There's a dropdown type if you want to constrain someone to a fixed list of options, but a support ticket ID is inherently open-ended text, so that escape hatch doesn't apply here.
The DIY layer that closes part of the gap
You can get closer with a GitHub Action. The issues event fires with an opened activity type, and a workflow triggered on it has the full issue body in github.event.issue.body, which is enough to run a regex against whatever the reporter typed into the ticket-ID field and act on the result: label it needs-info and comment asking for a correction if the string doesn't match your ticket ID's actual shape, like ZD-\d{5}.
That closes the format problem. It does not close the other two. Confirming the ticket actually exists means calling Zendesk's API from the Action, which means storing Zendesk credentials as a GitHub secret and building error handling for a service call your issue form now depends on. Keeping the link current as the ticket gets merged or reassigned means the reverse hasn't got a native trigger either. Zendesk has no built-in webhook for "update this GitHub issue when a linked ticket changes," so that direction is also something you'd write and maintain yourself. Format-checking is a reasonable half-day project. Two-way sync between a text field and a ticket that keeps changing underneath it is a small integration project, and building it means building the exact thing the form was trying to avoid needing.
Where this stops being a form problem
Put plainly: a required field is worth having for the reporters who'd otherwise skip the ticket number entirely. It stops helping the moment you need the number to still be correct, or need to know it's correct without someone manually re-checking every open issue against Zendesk by hand. Format validation via a GitHub Action buys you a bit more distance, at the cost of maintaining a workflow. Real sync, a GitHub issue that reflects a ticket's current status, or a ticket that shows the linked issue is still open, needs something watching both sides, which is a different kind of tool than an issue form.
We should say plainly that we built Modem. What follows describes our own product, not a neutral pick from the field. Modem doesn't add a field to the issue form at all. It reads issues from a connected GitHub repo as feedback, the same way it reads Zendesk, Intercom, Slack, and email, and matches activity to the person and company behind it using the identity already attached to each source (an email address, an account, a company domain) rather than a string someone had to type correctly. A self-hosted customer's GitHub bug report and their Zendesk escalation about the same problem land in the same topic without either side referencing the other's ID, and if the Zendesk ticket gets merged, the topic still reflects the current one because Modem is reading Zendesk directly rather than a snapshot someone pasted into a GitHub form months earlier.
It doesn't replace triage inside the repo. The mechanics of moving an issue through needs-triage, priority labels, and a duplicate check still happen in GitHub, and our guide on how to link GitHub issues to the customers who reported them covers that manual convention for teams not ready to change tools. What Modem covers is the part a required text field can't: confirming the link is real and keeping it current after the ticket moves.
The realistic bar for the native approach
If your reporters are mostly internal or a small trusted set of self-hosted customers, a required field plus a documented ticket-ID format is genuinely enough. The failure mode is rare, and a human catches it during triage. Add the GitHub Action once "will send" and stale numbers show up more than once a sprint; it's cheap and it removes the most common failure without new infrastructure. Reach for something that reads both systems directly only once you're spending real time reconciling issues against tickets by hand, which is also the point where a required field stops being able to prove the two records still agree. For more on why "required" doesn't mean "correct" across GitHub issue forms generally, see why do half your GitHub issue reports skip the template, where the same enforcement gap shows up for a different field.
