I can't seem to properly configure for public access a Dashboard made from a Survey123 map. I've checked everything I can think of- Collaborate settings in Survey123; the map created in AGOL; the feature layer in that map; and the Dashboard. When I test it in an incognito window, I'm prompted to sign in. I've read some threads in here, read an esri document on Dashboard sharing, and prayed to the gods of GIS. Obviously, there's something I need to learn. I'm hopeful someone can lift me from my state of ignorance for I have seem to have no influence with the gods
Be well, be safe, everyone.
I've never thought to pray to the gods of GIS, but I'll keep that in mind during my next roadblock! Ha! One little sneaky element that can cause this issue for us is if there is a 'premium content' layer in the webmap. These layers have a little blue shield icon that says "subscriber" in their details page. They can be hard to spot post-add as you have to go to each layer's details page and see. For instance, here is a layer that is a premium content layer and you can see the shield I'm referring to: https://www.arcgis.com/home/item.html?id=658732a227624146ba8322a94bc6ad8c
Unfortunately, ESRI doesn't yet give you any warning when you inadvertently put a layer into a public webmap. Perhaps you don't have many layers to check and can, at least, rule this potential out in your quest? Hope this helps!
Blue Water GIS
Thanks for your reply. I did know about subscriber content, for Dashboards is user friendly about this warning. When I click on the options for sharing, subscriber content is available to click on to see if there are any layers so flagged.
And you can see that there is none. However, when I go into my content, I do get a message I'm unaccustomed to seeing- "this layer is editable and shared with the public." Assuming I need to keep it so, I choose "Allow Data Collection."
So, as far as I can tell... I'm still stuck.
However, I'm enriched by the collegiality of your prompt reply and helpful reminder to check for Subscriber Content. Much appreciated.
One last option for you to try. When opening your dashboard (and feel free to share the link to help the community troubleshoot with you), right click and choose "Inspect". I'm not sure if you're used this tool before, but you may see a red x in the upper right corner (see screenshot below). Click on that red x and the 'errors' on the page will be listed on the bottom. Oftentimes I can literally see the layer that is causing the kick-back to require the login info. Please note, I know literally enough to be dangerous in this realm, but have traveled down this road of trying to figure out my 'trouble layer' before. Good luck and follow up to let me know if this helped you out! Cheers!
Well, I'm happy to report that the inspect tool yields not red flags or X's that I can see- because I know nothing about coding on the back end.
I'll take you up on the suggestion to share the url. Here's the url if I just open the Dashboard, and below that is the url from the share option that triggers the log in prompt.
My goal is to simply teach high school students how to use Survey123 in the community and how to use that data to create a Dashboard to be shared back to the community. (So I created a simple 3 question survey yesterday, pushed it out on facebook, and got a quick healthy hit of 82 responses. Built the Dashboard- and feel free to critique- and am now ready to teach how to follow these steps. Can't quite cross the finish line, however.
Well, dang it. That was my last idea. Sorry! We do that same workflow all the time.....and it really shouldn't be that hard! If you need another example for your class utilizing Survey123 to populate an Operations Dashboard, here's one we did pro-bono for an amazing animal rescue/rehab facility in Costa Rica: Wild Sun Rescue Center - Wildlife Injury Survey & Dashboards | Blue Water GIS
Good luck and what an amazing organization you are working for! It's awesome to see the next generation harnessing these powerful tools at such an early age. Great work out there!
Thanks, Katie. I'll check that out.
I emailed Charlie Fitzpatrick, ESRI Education team, and he sent me this response: "When you make a Survey, there is the hosted feature service, a "fieldworker view," and a "stakeholder view." Use the "stakeholder view" in your map and make that layer public. The Fieldworker view is what the survey form uses, and you don't want to expose to the public the raw hosted feature service. Should be good to go if (a) the dashboard, (b) the map, and (c) all the map contents are shared with the public."
I'm investigating that now while multi-tasking with Sunday afternoon football and a cold IPA.
Even though the feature layer in the webmap is public I think the data/service the layer was created/copied from isn't. I've noticed this can happen when you use the Copy Layer menu option in web maps. I once did this to create a local copy of data in the interim while I requested group access for another user and found they still couldn't view the data because the copy was pointed at the same original service which was only shared to members of the group, even though my copied layer was shared to the user I was trying to give access to.