Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,457,441
Community Members
 
Community Events
176
Community Groups

Forms in conversation with JSM Request Types

To give some context on how we are using Forms with JSM. We are completely replacing the request form section of our Request Types with Forms. Having to create a custom Jira fields every time we want to ask a different question is extremely tedious and creates a ton of fields that we really don't need to be Jira fields because we don't need to track the data beyond that one request. Also the fact that you can't rename the fields in the agent view like you can in the request form view means you have to be incredibly mindful of the fields when you are creating them. 

The Forms interface is just so much easier to work with and we don't need every single question to be a custom Jira field. Whenever we DO want field data retained and reportable, we will create it and link it then as needed. Also it allows us to have dynamic content, which is huge for keeping requests simple for our employees to read and follow. 

There are a handful of constraints that we are running into at the moment that I hope gets addressed. If anyone knows if there is an active feature request open for any of these, please let us know in a comment so I and other can go upvote it. 

  1. Forms cannot have an attachment field. On some of our request types we allow users to upload screenshots and attachments. Forms, from what I can see, doesn't have this. If you want to have an attachment, you still have to use the Jira field on the request form, which leads to the second constraint. 
  2. Inability to reorganize request form sections. Forms are placed under the hidden fields section on the request form. So when presented in the portal, the Form will show up below any Jira fields on the request form. So if you need to use the attachment field, it will be above your Form and if your structuring your Form to BE the entire form, it just looks weird to have attachments at the top above everything. We need the ability to reorganize those sections and be able to put Forms above the Jira fields. 
  3. Forms doesn't have hidden fields. Similar to not having an attachments field, you cannot make a field hidden, which we use for pre-filling certain fields that we use in automation and workflows. So you have to use the already existing mechanic in the request form section. 

Honestly I hope that they complete replace the current Request Type mechanics with Forms entirely as long as they move all the current capabilities into Forms. 

1 comment

For #1 and #2, you are correct those features are not available yet and frustrating. I may be miss understanding #3, but are you trying to hide fields within the form? Have you used the Section option which makes the fields contingent in the form based upon a selection from another field above?

@Joshua Kapke A hidden field works differently. In a request type, in the request form area, you would classically add all the fields that you would need your customer/employee to fill in before submitting the request. 

In that area, you have the option to hide a field. When you hide the field, it prompts you to fill in a default answer for the field. This is very useful if you want to preset something like the Summary fields. 

We have a typical problem where people will attempt to fully explain their issue in the Summary field and try to type out like 5 sentences. So to stop that, we would hide the Summary field and preset it with something we wanted. 

Now that we have the Forms feature, we moved away from using the request form area of the request type and put everything that want in the Form. Since Form doesn't have the same capability to hide and preset a field for us, we still have to do that in the request form area of the request type. 

Does it still work? Yes.
Is it tedious for us to put fields in different areas depending on what we need to have happen? Also yes. 

Comment

Log in or Sign up to comment