I have an AGOL ownership based access feature layer view with S123 pointing to it and updating records in Ops Dashboard
When I create the dashboard it sometimes initially works, but then if i copy an paste the url to another tab it immediately fails. This was all working fine then suddenly stopped
I have cleared out the features and started from empty again but still same problem. Any help gratefully received
Is your survey set to use a specific version, or always use the latest version of S123? We had a few surveys stop working when they were stuck on a legacy version that conflicted with a recent update.
Thx for getting back to me
Can't get to bottom of this issue!
I'm having a similar problem, described in my recent thread here.
Not exactly the same, but I have a case with technical support open as we speak. Ultimately, we think my problem may have something to do with the say Survey123 is understanding the URL parameter for the GlobalId. I'm getting a "Failed to Submit" problem using the syntax you described above. We still aren't sure what's going on, but we will get to the bottom of it. I don't know what changed, but my issue seemed to start immediately after the April 13th update of AGOL. When did your start giving you problems?
I had a similar issue with a survey embedded in a dashboard and 2 issues were flagged by support. One was having 'jr:choice-name()' function within an equation. The second was using autocomplete for the appearance of a choice list. Our survey was initially created using Connect and stored in Enterprise.
Hope this helps.
I think I may have figured out what is the issue. It might have to do something with the editing settings you have configured for your feature layer. I got the same warning message when my users tried to edit an existing survey. For the "What features can editors see?" option, is it "Editors can't see any features, even those they add"? You have to switch it to "Editors can see all features" to allow users to access the globalId field (and include the Update features option) when they want to edit a survey that doesn't belong to them (at least that was the issue for my case). But we also need to make our survey public.
My organization is interested in releasing a public survey, and when you make a survey public, you also have to make the associated feature layer public. I followed the workflow and editing settings that Esri provided to secure the data and ensure that no one could edit or view the data (please see below).
We also have an internal (second) survey, based on the same feature layer from the first survey, to review and approve the surveys submitted. I created a view layer from the original feature layer (to view and edit the layer) and embedded the survey into a dashboard to create a user-friendly application. The application worked perfectly fine for me, but when I shared the application with my teammates to review, they mentioned that they could not edit any surveys since they got the "Editing is not possible because the record specified by the globalId parameter cannot be accessed" message.
After doing a bunch of testing and talking with my team, it finally hit me that the other users can't access the globalId field because of the editing settings (What features can editors see? - Editors can't see any features, even those they add) I configured. By creating a view layer to edit the data from the original feature layer, I thought my users could access the data with no problems. However, I created the internal survey from the feature layer with all the restricted editing settings. Because my account owns the survey and all other associated items, my account can view and edit everything, but not for the other users. Once I updated the "What features can editors see?" option to "Editors can see all features" (and included updating is allowed for the type of editing), my users were able to view and edit existing surveys. However, we need to make the data secure and hidden from the public for our purposes, so the editing settings have to be restricted. To get around that, we created a second view layer and based our internal survey on that view feature service to enable the appropriate editing settings to edit existing surveys.
It looks like everything is working, but I don't know if there are any repercussions (other than deleting the source layer) by creating a survey based on a view layer instead of the source layer.
Please let me know if anyone has done something similar or if you have found another workaround. I am curious to hear other people's thoughts.