A modular approach to forms / request types

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.

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:

1. Build each fieldset family once in a master form ("HR blocks master": Employee Details, Reason for Movement, Approvals as sections, every field linked).
2. 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.
3. 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.