nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Issue with URL parameters not populating custom fields in Portal forms

박상욱

Hello,

We have been using URL parameters to pre-populate internal values in our portal forms using the following format:
?customfield_<field id>=<value>&...

However, this functionality has suddenly stopped working since the beginning of March. We have confirmed that there have been no changes to our field configurations or specific field IDs.

We suspect this might be related to the recent updates regarding "limiting field schemes" or security hardening that took effect this month.

Could you please clarify if there have been any changes to this feature or if there is a new recommended method for pre-filling portal fields via URL?

Thank you for your assistance.

Accepted answers

박상욱

Hello everyone, this issue seems to be resolved.

Everything is working correctly now.

Thanks for your help.

All comments

Trudy P Claspill

Hello @박상욱

Welcome to the Atlassian community.

Can you provide a specific example of your use case? What is the type of the Form field? What exactly have you specified as the default value?

Is this for a Team-managed or Company-managed Space?

박상욱

Hello,

In our service, when a user clicks the "1:1 Inquiry" button, they are redirected to a Jira Service Management (JSM) form page. We use custom fields to automatically pass the user's ID and device information into the JSM ticket via URL parameters, which allows our VOC managers to track issues efficiently.

Here are the technical details of the fields:

Field Type: Short text

Default Value: None (The fields are empty by default)

Project Type: Company-managed project

According to our internal records, this functionality worked correctly until March 2nd (likely March 1st UTC). Currently, the fields remain empty even when values are provided in the URL parameters.

Thank you.

Trudy P Claspill

So, I misspoke.

Please provide an example of the URL through which you are passing those values.

How are you setting the values of the custom fields before you use those to pass data to the form?

Provide an example of the URL you are using with the variables that you are using.

Arkadiusz Wroblewski

Hello and Welcome @박상욱

Prefilling via URL works for some simple request fields, but I would not expect it to work consistently for all custom fields, especially where Forms or linked form fields are involved.

For this use case, I’d rather use a linked Form, hidden/preset request fields where possible

or automation to populate the custom fields after the request is created.

About your other Question i think there was a similar Q&A thread a couple of days ago with a customer portal visibility issue, and that one also appeared to resolve itself.

@Trudy P Claspill, I wonder whether this may also be connected to the rollout of Service Collection and Changes.

박상욱

Hello,

Here is a concrete example of the URL we are using (the company domain has been masked for security, but please let me know if you need the full URL):

https://<xxxx>.atlassian.net/servicedesk/customer/portal/1/group/4/create/28?customfield_10136={device}&customfield_10134={os_version}&customfield_10050={app_version}&customfield_10135={uid}

The values passed through these parameters are simple text strings, ranging from 2 to 20 characters in length. We have been using this method for a long time without any issues until now.

Thank you.

박상욱

Hi,

Thank you for the response. I'd like to provide more context on our specific configuration and why the URL parameter method is essential for our workflow:

Hidden Fields for System Input: We have intentionally set these custom fields to "Hidden" in the portal settings. Our goal is to prevent users from manually editing these technical values (like UID or device info). Instead, we rely on the system to populate them automatically via URL parameters so that our VOC managers can have accurate data.

Dynamic Data Requirements: Since this data (User ID, OS version, etc.) originates from our external app's environment and changes with every request, it must be passed dynamically. Static "preset" values or manual entry are not viable options for this use case.

Regression Issue: This setup (pre-filling hidden fields via URL) has been working perfectly for a long time. The fact that it stopped working precisely around March 1st (UTC) suggests a side effect of a recent update rather than an inherent limitation.

Simple Field Types & URL Example: These are simple "Short text" fields. Here is the URL structure we have been using:https://<xxxx>.atlassian.net/servicedesk/customer/portal/1/group/4/create/28?customfield_10136={device}&customfield_10134={os_version}&customfield_10050={app_version}&customfield_10135={uid}

Lastly, we need to confirm whether this is a technical bug caused by a recent rollout (like "Service Collection") or an intentional change that now prevents URL parameters from populating hidden fields. Knowing this is critical for us to decide whether to wait for a fix or develop a new integration method.