A modular approach to forms / request types

Question

JSM forms are reusable across request types, however the limitation of one form per request type seems counter-intuitive. A lost opportunity?

The ability to reuse forms would lend itself well to a modular build approach.

We could have forms for common fieldsets within similar request types, eg in a HR context:

* Employee Details
* Reason for Staff Movement 
* Approvals

Less repetition and easier maintenance. Instead I'm finding I need to build out a dedicated comprehensive form for each request type, reusing no forms at all.

Am I missing something here?

Olha Yevdokymova_SaaSJet · Answer

Hi @Ray Stone

You're not missing anything — the reuse in native JSM is mainly at the whole-form level, rather than letting you build a request from several reusable form modules.

And I agree that a modular approach would make a lot of sense for cases like HR, where the same blocks of information appear again and again.

If you're open to apps, another approach you might consider is Smart Forms for Jira, developed by my team at SaaSJet:

The way I'd approach your example is to treat forms as reusable workflow modules, rather than rebuilding one large form for every request type.

For example:

* Employee Details

* Reason for Staff Movement

* Manager Approval

Each of those can be maintained as its own reusable form and then used where it makes sense.

Another important difference is that in Smart Forms, you don't need to create a Jira custom field for every question in the form.

Form elements can exist independently from Jira fields, so you can collect detailed information without filling your Jira configuration with dozens of one-off custom fields.

You only map the responses that actually need to become Jira fields — for example:

* Employee ID → Jira custom field

While supporting information such as:

* Reason for transfer

* Additional comments

can remain inside the attached form and still be available as part of the Jira work item.

That makes the modular approach much easier to maintain, because you can design forms around the process and information you need to collect, rather than around your Jira field configuration.

For example, Employee Details could be:

* shared as a standalone external form by link;

* embedded on an intranet, website, or Confluence page;

* used to create a Jira work item automatically;

* attached to an existing Jira work item;

* added automatically as part of a workflow.

Then the next part of the process doesn't necessarily need to be in the same giant form.

An employee transfer workflow might look like:

Employee Details
→ creates the Jira request

Staff Movement Details
→ collected once the type of movement is known

IT / Access Requirements
→ added only if systems or permissions need changing

So instead of maintaining four almost-identical forms for onboarding, transfer, promotion, and offboarding, you maintain the reusable pieces and combine them at the process level.

External forms are useful here as well. A general Smart Form shared by public link can accept multiple responses, so something like Employee Details, Candidate Information, or Supplier Details can act as a permanent intake form rather than being tied to one JSM request type. Each submission can create a Jira work item with only the relevant responses mapped to Jira fields.

For forms attached to an existing work item, you can also collect additional information later and map only the responses that matter back to that same Jira work item.

That gives you more freedom to think in terms of:

Reusable intake → Jira work item → additional forms as the process progresses

Sami Shaik · Answer

Good question @Ray Stone , and no, you are not missing a hidden feature. One portal form per request type is the current design boundary, and @Ben Friedman _Ben_viter_io_ three workarounds above are the right tactical menu (the post-create form addition in his option 2 is underused and worth testing for your flow). What I can add after building this on large sites is the architecture layer: where the modularity actually lives when forms will not compose.

The reframe: your reusable modules are fields, not forms. A form is presentation. The data contract is the set of Jira fields your form fields link to. If every copy of your "Employee Details" block links to the same shared Jira custom fields, then duplicating the form costs you presentation maintenance only, while reporting, JQL, automation, SLAs and dashboards stay unified across every request type, because they all read the same fields. Atlassian's own doc makes this the stated purpose of linking: https://support.atlassian.com/jira-service-management-cloud/docs/link-a-form-field-to-a-jira-field/ So the modular build you want does exist, one layer down: fieldsets as shared custom fields, forms as disposable skins over them.

The maintenance pattern that makes duplication survivable:

* Build each fieldset family once in a master form ("HR blocks master": Employee Details, Reason for Movement, Approvals as sections, every field linked).
* Copy the master to create each request type's form and delete the sections that flow does not need. Forms copy within and across service spaces, so the master travels.
* Keep a small registry page: which forms carry which blocks, and a last-synced date. When a shared block changes, you update the master and walk the registry. Honest cost: N copies means N touch points. The registry is the difference between "20 minutes of propagation" and "we no longer know which forms have the old Approvals block."

One caution on conditional sections if you lean on Ben's single-form approach: the logic is section level, not field level, the trigger must be a radio, checkbox or single-choice dropdown (multi-select cannot trigger conditions), and a required form field cannot live inside a conditional section, which quietly limits how much of a mandatory fieldset you can branch: https://support.atlassian.com/jira/kb/use-forms-to-set-conditional-fields-in-service-projects/ Past three or four branches, one mega-form becomes harder to maintain than the copies it replaced.

And you are right that it is a lost opportunity. Composable fieldsets referenced by multiple forms is exactly the missing primitive, and it is worth filing as a suggestion at jira.atlassian.com so it gathers votes. Until then: fields as the atoms, a master per family, and a registry. Less elegant than references, but it holds at scale.

Ben Friedman _Ben_viter_io_ · Answer

Hi @Ray Stone to start of, yes, currently request types can present only a single form when a customer submits them on the portal.
there are some workaround you can consider, each with its tradeoffs:

1. instead of using shared forms, use the shared fields directly in the request type.Fields will copy with a duplication of the request type if you need to re-assign them in the configuration. downside is that this will present field behaviors and not forms behaviors, so logic between fields, for example, cant work.

2. add forms post create. From what i assume on your use case, this will mean that a user submits a super lean request initially, then, once a a request is created you can add a form. Depending on your usecase, you can decide on addig only the additional form, or both (base + extended questions) on that step, based on how you want the user to progress. in the request type itself, on the portal, you can communicate to the user so they expect follow ups.

2.b not sure if it works for your use case,  but i have worked with a company where it made sense for the company to create the ticket then assign it to the customer for further feedback. With this, the customer would already get a ticket with all the information they require.

3. add all in a single form. for all types, have 1 form that shows the relevant subsets of fields based on a user selection. since forms present logic based on a field selection value, there needs to be a question to the user that identifies the flow of the form. potentially, this will be the question that asks the user to name the request type itself. if that is the case, then the request types are combined into a single ticket, at least at first. for the next steps of work you can decide if the team should move it to be another request type for purposes of reporting/workflow considersations.