Collecting forms for many uses, best practices?

[Alex Hall]

I support a department with a wide variety of teams, needs, and functions. We collect requests from employees both internal and external to our department, as well as non-employees from around the world. Our requesters will have a mix of i) Jira Software license, ii) Customer account, iii) no affiliation with our Jira instance/site.

We're exploring using JSM Forms for many of our frequent and structured requests. New hires, report requests, communication plans, etc. The majority of the people doing the work will be in Jira Software, and very few of them will be in JSM.

I was wondering if anyone had tips or tricks for similar situations, or if anyone had thoughts about whether we should have a dedicated project that solely exists to collect form submissions and direct the results via automation to various JSW projects, or if it's fine to include these in our more general service desk intake project. I think either would work, but doing things the best way is something I try to strive for. The answer here just isn't clear to me.

[Samuel Gatica _ServiceRocket_ · Accepted solution]

Hi @Alex Hall 

In your situation, both approaches—utilizing a dedicated JSM project for form submissions or incorporating them into a more general service desk intake project—can be effective, though each has its advantages depending on your specific requirements:

Dedicated JSM Project for Form Submissions

• Pros:
  • Clear Separation: This method maintains a distinct separation between form submissions and other service requests, facilitating easier management and analysis of data specifically related to forms.
  • Simplified Automation: Automation rules can be tailored to route these forms to the appropriate JSW projects without interference from other service desk processes.
  • Scalability: It is generally easier to scale and manage as the volume of forms and requests increases.
• Cons:
  • Maintenance Overhead: Managing a separate project may necessitate additional effort regarding configuration and upkeep.
  • User Confusion: Requesters may become confused about where to submit their requests if they are presented with multiple project options.

General Service Desk Intake Project

• Pros:
  • Unified Management: All requests, whether submitted through forms or traditional service desk channels, are managed from a single location, enhancing tracking and reporting on overall activities.
  • Reduced Complexity: Fewer projects to manage can help decrease administrative overhead.
  • Consistent User Experience: Requesters benefit from a single point of entry, which simplifies their overall experience.
• Cons:
  • Complex Automation: As the project becomes populated with various request types, creating and managing automation rules may become more complicated.
  • Potential Clutter: Mixing diverse types of requests could make it more challenging to focus on the specific needs related to forms.

Recommendations:

• Begin with a Dedicated Project: Given that you are still exploring options and that the majority of work will be conducted in JSW, starting with a dedicated project may facilitate easier management and adjustments as you refine your processes.
• Utilize Automation for Routing Work: Once forms are submitted, employ JSM automation to direct them to the appropriate JSW projects based on predefined criteria.
• Monitor and Adjust: As you collect more data on system utilization, you can determine whether to maintain the separate projects or consolidate them into a more general intake project.

This approach provides flexibility and control, enabling you to scale and adapt as needed without disrupting existing processes.

Hope this helps!

Best regards

Sam

[Josh Costella · Accepted solution]

Hi @Alex Hall 

I would consider having more than one JSM project/portal. One dedicated specifically for external (non-company) customers. And the other covers all internal users and requests. While you could do it all in a single project, it makes it easier and more secure to split it up, if possible.

Ultimately, just make sure request types are grouped in a way that makes the most sense. Make sure they are easy to understand. Use descriptions for the request types. 

I would recommend anything HR related be put in its own JSM project and secured as appropriate with permissions and issue security. Better to set it up now than risking something sensitive being seen. 

You can restrict request types by user group now so consider utilizing that as well. 

There's a lot of good info here: https://support.atlassian.com/jira-service-management-cloud/docs/configure-a-classic-service-project-as-an-administrator/