Not having logins makes the workflow difficult as for the public to update, they need editing, and your service would be publicly editable.
My understanding is that users need an account to edit in Field Maps. For Survey123... theoretically they can collect new records in the field app if launched via a URL but they won't have access to the inbox.
I don't believe there are any great solutions as by nature of what you are doing, for a user to 'update' the work, the layer or view would need to be editable and shared publicly. Maybe you could accept the security issue and expose just one field for updating status, but then the users would be constrained to updating via a web map. This is in addition to any member of the public flagging the work as complete, when it is incomplete or they are otherwise not responsible for flagging it as such.
It's also difficult to work with data in related tables. So if you have a 'point issue' feature layer with 3 related tables, and continue to capture related data via a one-way add only url scheme targeting the form_id of the repeat, it won't be able to 'update' the symbology or classification on the point layer in the map. Any automated update - e.g. webhooks or python scripts - are just a proxy for public editing.
You can use Arcade to drive the pop-up information.
So... not really the solution you are looking for but I would have something like:
- Public web survey for users to submit issues (one-way adds only targeting a point layer)
- Public web map for users to view submitted issues (no editing, potentially filtered to 'reviewed')
- Public web map has a pop-up from the point layer. It has a custom URL to a table related to the point. Passes globalid into parentglobalid field. Allows for users to submit followup requests. Can have more tables and forms here.
- Then... users with logins - be it staff or nominated 'superuser' volunteers - get provided logins to edit. They can review the submitted data, use webhooks, web maps, field maps batch editing tools, web mapping applications, survey123 inbox... anything, to edit the data as desired.
If you must allow the general public to edit the existing data, and we can't use Field Maps or Survey123 Inbox, you need to make a public web mapping application. I'd recommend:
- Hosted Feature Layer View with strict editing settings
- No geometry updates
- No deletes
- No Adds
- Only display fields you want to see; and
- Disable editing on each field you don't want to add
- The above should be clearly marked as public and intentionally so (security tools will check for publicly editable services)
- Make the Web Mapping Application:
- Likely in Experience Builder or Instant Apps
- With purposeful functionality - i.e. just the edit widget
- Add terms of use, and a splash screen to acknowledge, if you can
If you want to make a web map to show work completed (no editing), make additional views and have them non-editable. Then choose a web mapping application to align to the purpose -e.g. dashboards, or experience builder with other widgets.