Best practices for organizing tickets from forms?

Question

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 · Answer

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 · Answer

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 · Answer

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:

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

I hope it helps