Best practices for organizing tickets from forms?

[Yancey Larochelle-Williams]

My team wants to start allowing stakeholders to submit requirements directly into our backlog. I have a couple of ways I could accomplish this, and I wanted to understand what everyone has tried to make a scenario like this work.

• Option 1: Use the new form feature to allow users to create stories (we already have fields for acceptance criteria and requirements, but this doesn't allow us to separate by source - can't hide a label on tickets created by the form like you could in JSD, for example)
• Option 2: Create a discovery project (really heavy process and is not transparent to engineering)
• Option 3: Create a new issue type (splits the difference between the two - with the advantages and weaknesses of both)

What would you recommend? Am I missing anything else that might be better?

[Olha Yevdokymova_SaaSJet]

Hey @Yancey Larochelle-Williams 👋

This is a super common challenge — getting clean, structured input into your backlog without overwhelming your team or losing context.

You’re right that each of your options has trade-offs:

• Forms in Jira Software are handy but limited — you can’t hide metadata like labels or capture where the submission came from unless the user fills it in.

• Discovery projects are great for idea management but can feel like an extra step if you just want to capture structured requirements quickly.

• New issue types help you segment but come with overhead and still don’t fully control the input quality.

---

Here's another option worth considering:

If you're open to a Marketplace solution, Smart Forms for Jira lets you:

• Use hidden fields to tag the issue with source info (e.g. label = stakeholder-form)

• Add conditional logic so the form adapts based on what’s needed

• Automatically create specific work item types based on answers (Story, Task, etc.)

•  Route issues to the right project, component, or assignee

•  Keep the form short for submitters while mapping key data to Jira fields or mapping all answers to one description field.

It basically lets you build a form intake system across Jira (even from external users if needed), while still feeding your backlog with structured, triaged work — all without muddying up your custom field scheme. And it works across all Jira projects, JSM and JPD.

Happy to share a setup example if you're curious!

[Stephen.Lugton]

Hi @Yancey Larochelle-Williams 

It does depend on what the team wants to get out of allowing stakeholders to submit requirements to your backlog.

A simple way of differentiating where a requirement came from would be to use the reporter field; set up an automation with an if / else condition.  Firstly, set up a group for team members, then check in the if whether the reporter is a member of that group, and if not add a label e.g. 'Raised-by-stakeholder'.  You would then just have to keep the group up to date.

You could also add in triage / refinement steps to the workflow that don't then appear on your board, e.g. additional statuses 'For triage', 'Accepted', 'To be Refined'

[Matteo Vecchiato]

Hi @Yancey Larochelle-Williams ,

interesting question. I think it is not possible to define if you are creating a work item thorugh a form or standard mode.

In my opinion, Option 2 and 3 create data stored in differents way, that is not a good solution.

But searching for a solution, I would suggest in order of preference:

1. Maintaing the same work type and introduce a custom field "source" as required field (and it works with form too)
2. Split in 2 different work types

I hope it helps