One Form - Multi Approval

CHESTER RAMOS

Hi there,

We are on the verge of implementing JIRA Cloud Service Desk but we would like to limit the numbers of forms.

At the moment our setup is based on System Owners.
Meaning, all request that is related to HR Systems have one forms, same goes for IT, Finance...etc

We were wondering, is there any way we can deploy one form in which

Question1:

Based on Multi cascading fields

If a requestor selects a secondary cascading field which is not equal to N/A/Null value, it means the it will be routed to the system owner via email notification for approval

What it means is that the service request form will have
multi first approver options based on the cascading field values.

Is this possible?

 

Question 2

 

Do I need multiple cascading fields (Cascading field for HR, Cascading field for IT, Cascading field for Admin..etc) for this setup to work?

 

Walter Buggenhout

Hi @CHESTER RAMOS,

Atlassian just announced the acquisition of Thinktilt, the company that built Proforma. It will probably take some time before that will lead to a fully integrated solution in the tool, but you make expect a lot of dynamic forms funtionality and easy design to come in the near to mid-term future.

Having said that, I think it is wise to see screen design and approval as different things.

About the screens first: HR, IT and Admin are usually different departments, so they will internally work on different sets of issues. It does not seem like such a strange idea that very different permissions will apply to those requests too. I can imagine that a request to HR should not always be visible to IT. Creating all tickets from the same screen means they will initially all end up as one big pile of issues that can only be distinguished by selected attributes. So they will all have the same issue type, workflow, custom fields that are not relevant, ... And you'll need to implement a lot of automation rules to automatically triage all that, communicate with your end user about the ticket and so on.

Approval is a workflow matter. You can read more about the process, starting from this support article. Basically, how you set up your approval process is not directly related to the screens being used to specify what requests are about. As long as the information is there, obviously.

Thinking from the user perspective (i.e. the people creating tickets) - it is essential that they can find the right type of ticket to enter a request. And on top of that, be able to do that as easily as possible. From my experience, most users can identify if their request is for IT, HR or rather Admin. And usually we set up service desk projects for those departments. That narrows the complexity of the form design down to just the domain of the departments. And you still can use the design tree you already have to further map out what is needed where.

I hope this is some useful food for thought!