Can I calculate an attribute to be empty once survey is opened?

[Tiff-Maps]

Hello, I have a few surveys set up that are meant to be submitted to by the public. We are essentially crowd sourcing information so that when someone finds that the information is no longer correct or relevant, they can request to change it. However, that means that if one person submits a change and provides details about it, a second person may want to submit a change and I would not want the first person's notes to appear where a blank question should appear. I have this set up to update the feature service directly, with a review process where the data is added or changed only after it is reviewed.

In my xls form calculation I have something like: if(${Notes}, '', ${Notes}, '') meaning to set it to empty. I can't calculate it to null by doing '' as it also throws an error. I am not sure if either are good ways to do this. The error I am getting is the XPath dependency cycle (thread here) in which Esri staff mentioned: "fields cannot refer to themselves in a calculation, as that might cause an endless loop."

Is there another way to achieve what I am looking to do? I know it's possible to collect that info in another feature layer but right now the review process is set up pretty well with my current structure. I don't believe there is a workaround (for example, having multiple fields for different notes purposes)  as there is always the chance someone will request a change to the same listing. 

[ChristopherCounsell]

I think you may already know the answer - you can't really expose a table to be updated by the public without putting a bunch of technical debt down the track. Having a single-table setup with updates doesn't really allow for concurrent editing, and also means your service URL is publicly exposed with updates enabled.

Not sure where you are at but take two examples:

• Existing public assets (toilets) that you want the public to submit reports to
• Non-existing assets that you want the public to report, and then allow for additional information to be provided (the updates)

Both of these scenarios are well-serviced by a one-to-many relationship of point-table. You, or an initial member of the public creates the point, then additional surveys add information to the related table.

This allows you to capture all reports, but only ever allows the public to add data. You can hide all reports from the public using default values. 

Here's a very old video showing the workflow principles:

https://www.youtube.com/watch?v=vECznnoJHGk

and more info:

https://community.esri.com/t5/arcgis-survey123-blog/survey123-tricks-of-the-trade-repeats/ba-p/89804...

https://community.esri.com/t5/arcgis-survey123-blog/working-with-existing-feature-services-in-arcgis...

[Tiff-Maps]

Thank you for your response @ChristopherCounsell. You are totally right- there are definitely limitations to the way I'm doing it...however, I think I will opt for an archived notes field and limit the removal/update survey (and thus the public view layer) to just a few fields.  Right now I have internal surveys embedded in a dashboard to review the submissions/requests. That review workflow doesn't seem as easily done with a related table which is why I'm hesitant to go that route. I might have to think more into it.

[Tiff-Maps]

UPDATE: Problem has been resolved! solution in this forum: https://community.esri.com/t5/arcgis-survey123-questions/issues-with-public-survey123-to-collect/m-p...

HI @ChristopherCounsell . I took your suggestion and am now working on this. The process for internal review was actually very easy to accommodate (just another dashboard) but I am now having issues in actually sharing the survey to the public. I am 80% there and have tried to troubleshoot issues along the way but wanted to reach out to you about what you mentioned on "you can hide all reports from the public using default values". Before I changed the settings to add-only, I was able to add a related record. Unfortunately I then noticed that once a related record exists for a feature, if someone were to submit another request (say, other information changes), they see the autopopulated record already (I would rather have them see no existing data and only be able to submit new records). This issue may be because of the mode=edit parameter but that is required I think for the URL parameter in the pop-up to access the global ID.

Once I changed the editing to add-only, I am now getting the following error as a result: Editing is not possible because the record specified by the globalId parameter cannot be accessed. If I use mode=view parameter I am getting the error: You do not have permission to view this survey record. I guess this is technically two separate issues.

Do you have any thoughts or suggestions? Honestly I was not too keen on using related tables because I know there are a lot of issues and limitations with Survey123. I feel that this must be possible given the use case you provided on submitting on existing assets. But I am completely stumped on how to do this with the settings and URL parameters.

Another similar issue I have worked around is that when reviewing submissions in a dashboard (embedded survey), even if there is no related record pertaining to that feature, it creates blank records. It looks like that is a documented and not yet resolved issue (forum post here). To mitigate this I actually had to create TWO review surveys, one with and without the repeat.