Much of the functionality in Crowdsource Polling is driven by the structure of the layers that are included in the maps displayed by the application. The app doesn't require a specific schema for these layers, but additional app functionality can be exposed or controlled based on the structure of these layers. Many of these options can also make it easier for your users to submit valuable reports, and for you to manage those reports as they are received.
To create an empty crowdsourcing layer, use an existing service to create a new hosted feature layer in your ArcGIS Online organization, Portal for ArcGIS, or ArcGIS Enterprise. The Service Catalog contains several feature layers that can be used for this purpose.
Alternatively, use the following workflows to create one or more layers with exactly the attributes you need for your crowdsourcing workflow:
- Moderate reports
- Validate report information
- Set required and optional fields
- Collect supporting documents
- Enable or disable voting
- Enable or disable comments
- Capture reporter identification
- Symbolize reports using data values
- Track when reports are submitted
- Record the location of reports
Moderate comments
It is important with most public-facing apps to have a way to moderate which feedback is publicly visible. In some cases, this may be as simple as restricting who can see the application to only members of your organization, or members of a specific group within your organization. In other cases, where feedback is coming from the public, this can be controlled with a combination of default values and filters on the comment table. Moderating feedback can be set up three ways:
- Only show comments that have been explicitly approved
- Approve all comments immediately with the ability to hide them after the fact
- Hide or show comments based on attribute values
The set up for all the first two options is similar:
- Add a field to the table layer for controlling comment visibility. This field should accept values from a domain that contains two values — one for when the report is visible, and one for when it is not. For this example, I'll use a field called PUBLICVIEW that uses a domain with the values YES (for when the comment is publicly visible) and NO (for when it is not).
- Use the default value of the field to control if reports will only appear after they have been approved (set the default value of the field to NO), or if they will appear immediately (set the default value of the field to YES).
- Once the layer is published and added to a map that will display in Polling, set a filter on the table layer so that only approved comments display. For example, set the filter to PUBLICVIEW is YES.
- Turn off the ability to view or edit this field through Polling by turning this field off in the table layer pop-up.
- Add the same layer to a map that will be displayed in an editing environment such as Crowdsource Manager. In this map, this field should be both visible and editable, without a filter applied, so that your data managers can update the value to moderate the comments.
If the reason for moderation is data sensitivity, consider protecting your data further by implementing rate limiting and requiring credentials to access the layer except through your Polling and Manager applications.
Validate report information
Consider the following ways to make it easier for your users to submit valid information through Polling, and to make it easier for your data managers and others who may use the layer:
- Use coded value domains to present a drop-down list of values. This can be useful for status values, lists of names or departments, and any other field that will require a value from a known list of possibilities.
- Use range domains to restrict numeric and date values. If all values are expected to fall within a defined range, set upper and lower limits to the values that can be entered. For example, to collect damage reports from a recent storm, require reports to be submitted with dates on or after the storm date.
- Pre-populate fields that will typically have a specific value by setting a default value. An example of this is the comment moderation workflow, but this could also be as simple as setting the default status of comments as they are submitted.
- Specify the field length to prevent extra information from being included. For example, if a field collects a 5 digit ZIP code, set the maximum field size to 5 to prevent users from entering the 9 digit code instead.
Require values
If there is information that must be included with a comment, consider setting the field that stores that information so that it will not accept null values. Keep in mind that if a field does not accept null values and does not have a default value it must be made editable in the table layer's pop-up configuration.
Collect supporting documents
Polling allows files such as photos and PDFs to be submitted along with comments. To turn on this capability, enable attachments on the table layer prior to publishing or from the details page of the feature layer item.
Enabling and disabling voting
Polling can be configured to allow users to vote for features. To enable voting, the feature layer must have a numeric field for storing the number of votes accumulated by each report. The name of this field is specified when configuring the application. To allow for more complex voting than a simple upvote, consider using the comment form to have users provide identifying information or to provide quantitative feedback.
To disable voting, leave the Vote Field parameter in the application configuration blank.
Enable and disable comments
As well as voting, users can provide feedback on previously submitted reports in the form of comments. Commenting is only available on layers that have a related table for storing the comments. Set up the table and the relationship following these steps:
- Build a geodatabase table that contains fields for all the information to be collected in the comments. This may be a single field, or it may be a series of fields for collecting the comment, identifying information, contact information, and so on.
- Add Global IDs to the feature layer. This will add a Global ID field to the layer and assign an ID value to each report as it is submitted. This field will be the primary key in the relationship between the features and the comment table.
- Add a field of type Guid to the table. Fields of this type do not auto-populate with GUID values, but they can hold GUID values generated elsewhere. This field will be the foreign key in the relationship that will exist between the features and this table, and as each comment is submitted this field will be populated with the GUID of the source report.
- Create a one-to-many geodatabase relationship between the features and the table using the feature layer's Global ID field as a primary key and the table's Guid field as the foreign key.
- Publish the layers and add them to a map that will be displayed in Polling. As well as configuring the pop-up for the feature layer, configure the pop-up for the table layer. The comment table layer's pop-up display configuration will be used for displaying the comment in the app and the editing configuration will be used to build the comment form.
Commenting can be disabled temporarily by editing the table's pop-up configuration so that no fields are editable or visible.
Track when reports are submitted
It can be valuable to know exactly when a comment was submitted, and a user-supplied date is not always the best way to record this. To keep track of when each comment was created and edited, open the details for the layer and enable the option to Keep track of who created and last updated features. While this won't allow you to track who submits anonymous comments, it will stamp each report with the date it is created.