nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Quality Control Suggestions Wanted

JoshBillings

Hey all,

I have published an Events Dashboard that staff in my Recreation and Parks department contribute to via a Survey.

There are 4 main supervisors who are responsible for 8-10 staff each. None have any type of GIS experience.

ALL of the staff are submitting events via the Survey.

I have tried to make the Survey as simple as possible by providing predefined choices where necessary, but errors are still being made - especially in areas where data can't be predefined, such as a description of an event.

I am trying to develop a hands-off approach where all I am responsible for is dashboard maintenance, while supervisors are responsible for data integrity (correct grammar, checking for spelling, etc.).

Since I am the author of the survey, I can't allow the supervisors to go in and make edits themselves - this currently isn't allowed in Survey123.

I am in need of some sort of QC Check process that goes through staff and supervisors before it is uploaded to the events dashboard (by staff).

Does anyone have a system in place or have any suggestions on what I could do?

Thank you!

Najděte více příspěvků označených jako

Accepted answers

jcarlson

This can get quite complex, but it's possible using a variety of Layer Views together with Survey123 Connect. We have a document approval workflow that we use Survey for, and it could probably work for this.

On your main layer, add fields called something like department and reviewed. (You might not need department, I'm not sure of your situation.) Create domains on the fields to constrain the department choices and set the default value of the reviewed field to no / 0. I like to use an integer field for boolean values, but they could as easily be literal strings of 'yes' and 'no', just as long as they're consistent.

Create a number of view layers, and define their views.

Staff View

This would be similar to what you're using now in terms of sharing and editing settings, and would use whatever survey is in place. Hide the reviewed field.

Supervisor View(s)

Define the view as features where "reviewed = 'no' or reviewed is null". Allow attribute edits, but no adds/deletes. Expose only those fields which supervisors need to review / correct.

Create a new survey that references this view layer. Make that survey expose the attributes that need reviewing and correcting, and include a hidden question to set the reviewed field to "yes" upon submitting.

Create a dashboard that lists the features in this view with a linked Embed element that goes to the URL "https://survey123.arcgis.com/share/<survey-itemID>?mode=edit&globalId={globalid}&hide=theme,header,footer,navbar"

Share that dashboard with supervisors only, perhaps through group sharing settings. If your supervisors are specific to certain departments, you can repeat this process for each one. In my org, our County Treasurer and Clerk each have their own dashboards like this:

Public View

Define this view as features where "reviewed = 'yes'". Turn off all editing and make public. Use this to populate your final dashboard.

Like I said, complex, but the end result is a two-stage process in which only "reviewed" items will make it to the final dashboard.

All comments

SamanthaAPCC

Hello @jcarlson! I'm fairly new to both Survey123 and Dashboards, but I am attempting to create a review dashboard like the one you've shown above. This would fit our needs exactly. Can you elaborate a bit more on this section:

I created a new survey based on the view layer, but how do I reference fields from the view layer and also how did you create the hidden question that sets the reviewed field to 'yes' if the user selects 'yes' in the dashboard? Could you share a screenshot of your xlsForm for this new survey?

Thanks for your help!

Samantha

JoshBillings

@jcarlson You're the man. It's working 100% now.. Thank you so much for your help!

jcarlson

Ah, that's probably the sharing settings. Even if your "supervisors" layer is editable, it needs to be shared publicly to be edited by non-Creator user types.

We've never had anyone spam our view layers, but it's another reason to use the embed in the dashboard. Even though the survey and view layer are public, the dashboard isn't, so there's at least a little more control.

JoshBillings

@jcarlson This will work perfectly!

I have everything set up, but when a supervisor attempts to submit any changes on the embedded form, it gives an error that says "Failed to submit" without any further information.

Have you ran into this issue at all?

jcarlson

Create a number of view layers, and define their views.

Staff View

This would be similar to what you're using now in terms of sharing and editing settings, and would use whatever survey is in place. Hide the reviewed field.

Supervisor View(s)

Define the view as features where "reviewed = 'no' or reviewed is null". Allow attribute edits, but no adds/deletes. Expose only those fields which supervisors need to review / correct.

Public View

Define this view as features where "reviewed = 'yes'". Turn off all editing and make public. Use this to populate your final dashboard.

Like I said, complex, but the end result is a two-stage process in which only "reviewed" items will make it to the final dashboard.

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.