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.
Hello everyone, this issue seems to be resolved.
Everything is working correctly now.
Thanks for your help.
Hi @박상욱
To me seems like this is impacted by a change made by Atlassian.
As I have seen multiple questions on the same topic @Arkadiusz Wroblewski and @Trudy Claspill
I think raising an issue with Atlassian Support is your best option, as it seems it might be a bug due to an implemented change.
The questions which one, they should be albe to investigate.
I have asked Atlassian Support for assistance on this issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, we recently answered on a couple of similar topics, so it does look like this might be something Atlassian-related.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 Claspill, I wonder whether this may also be connected to the rollout of Service Collection and Changes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
Thank you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.