I'm beating my head against a wall here. I'm working on integrating Field Maps and the Survey123 app to update our one of our data collection workflows. Monitors will enter a point, line, or polygon in Field Maps, click a link in the pop-up which will send them to the survey which is stored in a related table in the hosted feature service.
I've got an an Arcade script that will give a url to collect new monitoring notes and tie it to the feature by passing the feature GlobalID to a GUID field in the table if no existing record is found (which works great). What I'm struggling with is getting Survey123 to open an existing entry for editing. I'm trying to get it to find an existing monitoring note record by querying the GUID field for the related feature's GlobalID. The only query I can get to work on the table is the table's GlobalID field for an ID that I manually paste in: "q:GlobalID": '56bc00cb-4c8d-4e60-8553-a87dd98697cd', will open survey123 with that particular record opened for editing. Nothing else will work. When I click the link to edit a record, it just takes me to my inbox and shows all the entries. If I go too wild with trying to create a where= query shown in the Integrating with other apps page Survey123 gives me a code 400 error for invalid parameters.
Here's the script:
Solved! Go to Solution.
I solved my own problem. The issue came from using the UrlEncode on the q:queryparameters, it would change 'where=' to 'where%3D' which appears to be the only part of the query that will cause the query to fail if it is encoded.
q%3Awhere%3Dpoint_guid=%279462d173-fae1-42ca-a5ab-52afa8f417bb%27 <-- Does not work.
q%3Awhere=point_guid=%279462d173-fae1-42ca-a5ab-52afa8f417bb%27 <-- Works
I encoded the URL minus the query and attached it to the encoded url after setting it up as a Text formatted string, making sure to include the & .
The order of all the parameters does not appear to matter, so attaching the query to the end of the encoded url seems to work without issue. I did test it with apostrophes around $feature.GlobalID and it automatically converted them to %27, so I decided to use %27 in place of the apostrophes to prevent any conversion failures.
I solved my own problem. The issue came from using the UrlEncode on the q:queryparameters, it would change 'where=' to 'where%3D' which appears to be the only part of the query that will cause the query to fail if it is encoded.
q%3Awhere%3Dpoint_guid=%279462d173-fae1-42ca-a5ab-52afa8f417bb%27 <-- Does not work.
q%3Awhere=point_guid=%279462d173-fae1-42ca-a5ab-52afa8f417bb%27 <-- Works
I encoded the URL minus the query and attached it to the encoded url after setting it up as a Text formatted string, making sure to include the & .
The order of all the parameters does not appear to matter, so attaching the query to the end of the encoded url seems to work without issue. I did test it with apostrophes around $feature.GlobalID and it automatically converted them to %27, so I decided to use %27 in place of the apostrophes to prevent any conversion failures.