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
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?
Do I need multiple cascading fields (Cascading field for HR, Cascading field for IT, Cascading field for Admin..etc) for this setup to work?
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!
Project managers know this problem: A “mountain of work” lays in front of you, and you don’t know how and where to tackle them. Different to-dos lie ahead, but just one task after the other can be ha...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events