Hi everyone,

I should have created this right when Adam told me, but I just put in this suggestion to maintain these parameters across the service desk:  https://jira.atlassian.com/browse/JSDCLOUD-9270

Feel free to vote on that one if you are interested.  We need to be able to maintain details about our customers that we already know about them as they navigate around our portals.  Huge thanks to Adam for getting us started and giving us what we have today for single request types!  Hopefully we can get this followup portion implemented to make customers lives better.

It's sooo sad to see that Adam Hynes is inactive =( 
You made a great job, thanks a lot. I hope you'll see my message, bro

Hi greg.draper310998593,

Unfortunately, implementing this would require us to preserve URL parameters as a user navigates the portal. Some pages, like the My Requests page, have their own URL parameters that are used for pagination or result filtering, so we would have to make sure we don't interfere with existing parameters if we implemented this.

Because of this complication, while it's possible, implementing what you ask for would require some extra work than just preserving URL parameters across all pages. Unfortunately I won't have time to implement this myself. If you feel you need it, then go ahead and create a new Suggestion ticket.

Thanks,

Adam

Hello again, Adam.  Still very very happy with this.  Is there any way to maintain the URL parameters through navigation from the top level of a portal?

e.g.  atlassian.net/servicedesk/customer/portal/2?summary=test  will then go to atlassian.net/servicedesk/customer/portal/2/group/37?summary=test and then to atlassian.net/servicedesk/customer/portal/2/group/37/create/140?summary=test as a user clicks through the portal

Was hoping we could do that somehow to maintain values as users navigate between multiple different request types.  I know this is generally possible to do, but it is currently not setup to do this in Jira Service Desk from what I am seeing.  Thanks!

This goes to the production right away. Thank you sooo much! 

I have been waiting for so long for this. It works great! You are awesome! Thank you so much!! 

Hi greg.draper310998593, cheers for the kind words, I would gladly accept that drink!

I did a quick test and yes, you can pre-populate the "Email confirmation to" field. That field has a field id of email, so all you have to do is add an email=newuser@test.com URL parameter and it should work.

Adam Hynes, I owe you a drink! This is one of the most critically needed features in the Jira ecosystem. If Jira Service Desk continues to get the love like this that it needs, Atlassian will be unstoppable. Definitely kudos to you for realizing that and you deserve a ton of praise. Now we finally have some sort of way to know who our customer is and pre-populate fields relevant to them on requests.

I will be implementing this in a bunch of places today and it feels like Christmas morning to me. One question... are we able to pre-populate the “Email confirmation to” on a login free portal? That’s me asking for the cherry on top (but I’ll still be happy if the answer to that is no). Someone give Adam a raise immediately.

Thanks for the kind words aragot1463073100.

For the components field, you need to use the component id. From your example it looks like you're using the component value as your URL parameter. From my test request create page, I have the following data for the components field in the JSON payload:

{
  "fieldType": "multiselect",
  "fieldId": "components",
  "fieldConfigId": "",
  "label": "Components",
  "description": "",
  "descriptionHtml": "",
  "required": false,
  "displayed": true,
  "values": [
    {
      "value": "10003",
      "label": "Active Directory",
      "selected": false,
      "children": []
    },
    {
      "value": "10004",
      "label": "Analytics and Reporting Service",
      "selected": false,
      "children": []
    },
    {
      "value": "10005",
      "label": "Billing Services",
      "selected": false,
      "children": []
    },
    // ...more components
  ]
},

If I want both "Active Directory" and "Billing Services" to be selected, I need to add two parameters like so: &components=10003&components=1005.

The same applies to the single select field. On my test request create page, I have a "priotity" single select field, with the following data in the JSON payload:

{
  "fieldType": "select",
  "fieldId": "priority",
  "fieldConfigId": "",
  "label": "Priority",
  "description": "",
  "descriptionHtml": "",
  "required": false,
  "displayed": true,
  "values": [
    {
      "value": "1",
      "label": "Highest",
      "selected": false,
      "children": []
    },
    {
      "value": "2",
      "label": "High",
      "selected": false,
      "children": []
    },
    {
      "value": "3",
      "label": "Medium",
      "selected": true,
      "children": []
    },
    {
      "value": "4",
      "label": "Low",
      "selected": false,
      "children": []
    },
    {
      "value": "5",
      "label": "Lowest",
      "selected": false,
      "children": []
    }
  ],
  "noneOptionRequired": false
}, 

So to set this field to "Lowest", I'd use the url param priority=5.

For your case, try to find "customfield_11011" in the JSON paylod and see what "value" corresponds to what you want.

This is absolutely awesome, give a public Kudos to Adam Hynes at the next all-hands!!! Write URL parameters is fine for a lot of people, and actually easy to use, once we explain them on the Atlassian forums. It's good that you went for the shortest increment that can be delivered to production. And it is already delivered to production!

It worked well for test fields, but I didn't succeed to find the right format for the Components and the single select field: https://playsql.atlassian.net/servicedesk/customer/portal/1/group/1/create/9?summary=test&description=test&components=Requirement+Yogi&customfield_11012=Data+Center&customfield_11011=test

Hi, Adam here, I’m a developer on the Jira Service Desk Cloud team.

I have just implemented this functionality for the Jira Service Desk Customer Portal, as a 20% time project (developers at Atlassian get time for innovation projects like this). For now, this is an undocumented feature. Think of it as being in beta, or in an “early access program”. Here’s a quick guide on how to use it…

Example URL

/servicedesk/customer/portal/2/group/526/create/58?summary=I%20need%20a%20laptop%20stand%20for%20my%20bike&description=I%20want%20to%20be%20able%20to%20get%20work%20done%20while%20I%27m%20cycling%20to%20the%20office.&priority=4&cus

The URL parameter key needs to match the Jira field ID of the field you want to populate. The field ids varies depending on the fields available and visible on that request type. All request types have a summary field, so that will always work. Custom fields can also be populated (see below).

The URL parameter value should be set to what you want the value of that field to be. For text fields and text area fields, this is a pain string. Other field types will have restrictions on what the value can be: for example, a “priority” field will only have a select number of options to choose from.

Invalid values

Some fields require values to be in a particular format, for example:

• Single select fields require the value to be one of the available options.

• Date and time fields require the value to be in a particular string format.

If the value supplied in the URL parameter for a field is not in the correct format, then that URL parameter will be ignored and the value will not be populated (the page will still load fine though). 

Custom fields

Custom fields can also be populated. The key to use is the custom field id. The following types of fields are currently supported:

• text

• textarea

• date

• duedate

• datetime

• checkbox

• radio

• labelpicker

• select

• multiselect

• cascadingselect

Other types of custom field are not supported.

Unsupported field types

The following field types are not currently supported:

• User fields, both single and multi select

• Attachment fields

Working out field ids

You can work out what the correct URL param key/value pairs are by analyzing the JSON contents of the <div id="jsonPayload" style="display: none;"> node in the  request create page HTML source, and looking at the reqCreate.fields property. Here you’ll find an array of objects, where fieldId is the key for the URL parameter, and the value is either just text, or one of the options defined there.

This is not very intuitive to use. A better solution would be a button present on the Request Create page that allows URLs to be generated based on the currently entered values on the page. Vote for that feature here: JSDCLOUD-8915

+1 to this. We need this to prepoluate the data about users when they click on the support link. It's stupid to make them fill all fields we do already know. And they also know we know 

We've been looking for this functionality for a while.

It would help with many areas in our business. A common request is for teams to pre-populate tickets for their team new hire onboarding or other routine requests. These vary completely between team, and are subject to change regularly so it doesn't make sense to hardcode into JIRA. Instead we could simply populate the fields in the URL, (i.e. /servicedesk/customer/portal/2/create/20?summary=do+this+for+user1&cc=...&description=...)

We offer customers to raise a support request from inside our plugin.

• We'd like to pre-populate the fields with their Server ID, SEN, and the basic debug data.
• We need a URL to Jira Service Desk, where we could provide pre-filled values for the fields inside the URL.

Thank you.

I would need this feature as well.

We have PCs - each has a unique ID. They have a sticker on it with an QR-Code. Customers can Scan this code for support and the Unique ID should be set automatically for a custom field in Service desk for us to do further Tasks.

I do not understand why this doesnt work :/

Please add this feature. 

Update:
Geez, just notices that this ticket has been created 2013. 
I am wondering if someone from Atlassian has even seen this Suggestion / Request yet.. 

Hi, my use case is to be able to pre-qualify the requests of the customers and redirect them via a dynamic url to the adequate customer request type and creation form (with the values prefilled).

I believe if this feature would be implemented it could help me to achieve this use case. So, could we have an update for planning of this feature ? 

Thanks for your time.

Here is the updated link for instructions on how to do this in regular JIRA - we really need the same functionality to be present in Service Desk: https://confluence.atlassian.com/jirakb/creating-issues-via-direct-html-links-159474.html

Create issue operation in JIRA supports populating field using URL arguments. Similar feature in service desk will help to pre-populate values on form.