A modular approach to forms / request types

[Ray Stone]

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?

[Ben Friedman _Ben_viter_io_]

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.