Much of the functionality in Crowdsource Reporter 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:
- Identify the right fields
- 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
Choose the right fields
The same data layers will be shown in both your Reporter and Manager maps, and may also be used in other workflows, for example by field workers using Collector or ArcGIS Survey123. For this reason, it is important to carefully plan the fields that will be included in this layer. Consider including fields such as:
- Fields for the information to be collected
- Identification and contact fields
- Report date field
- Fields for moderating reports
- Fields for triaging reports
- Report status field
- Fields required by other workflows
None of these fields are required in order to use your layer with Reporter, but including these fields may help your users submit more meaningful reports, streamline your report management workflows, and help integrate these reports into your workflows with other ArcGIS apps.
It is important with most public-facing apps to have a way to moderate which reports are 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 reports are coming from the public, this can be controlled with a combination of default values and filters on map layers. Moderating reports can be set up three ways:
- Only show reports that have been explicitly approved
- Approve all reports immediately with the ability to hide them after the fact
- Hide or show reports based on attribute values
The set up for all the first two options is similar:
- Add a field to the layer for controlling feature 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 report 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 Reporter, set a filter on the layer so that only approved reports display. For example, set the filter to PUBLICVIEW is YES.
- Turn off the ability to view or edit this field through Reporter by turning this field off in the 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 reports.
To hide or show reports based on attribute values, follow steps 3-5 above, but set the filter on the field containing those values. For example, to hide the locations of endangered species, while allowing other reports to display, set a series of filters on the species name field that dictate when the reports should be made visible or when they should remain hidden.
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 Reporter and Manager applications.
Validate report information
Consider the following ways to make it easier for your users to submit valid information through Reporter, 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 report moderation workflow, but this could also be as simple as setting the default status of reports as they are submitted. By default, Reporter assumes the default value for date fields is the current date, unless another default value or a conflicting range domain has been specified.
- 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.
If there is information that must be included with a report, 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 layer's pop-up configuration in the Reporter map.
Collect supporting documents
Reporter allows files such as photos, PDFs and videos to be submitted along with reports. Supported video formats are MOV, MP4, MPA, MPE, MPEG, MPG and MPV2. The maximum each attachment can be is 10 MB. To turn on this capability, enable attachments on the layer prior to publishing or from the details page of the feature layer item.
Enabling and disabling voting
Reporter can be configured to allow users to vote for reports that have been previously submitted. To enable voting, your layer must have a numeric field for storing the number of votes accumulated by each report. If your app will have several layers, the vote-counting field must have the same name (case-sensitive) in all layers. The name of this field is specified when configuring the application and the vote button will only appear on reports in layers that have this field.
To disable voting on a single layer while leaving it on others, remove the voting field from that layer. To disable voting across the application, 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. To track comments submitted by signed-in users, include a field with the same name as the other user ID tracking fields found elsewhere in your layers.
- 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 Reporter. As well as configuring the pop-up for the feature layer, configure the pop-up for the table layer. Just like with the feature layer, the comment table'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.
- In the application configuration panel, choose to use the comment table pop-up configuration to display comments
Commenting can be disabled temporarily for a specific layer by editing the table's pop-up configuration so that no fields are editable or visible. To disable commenting across the whole application, edit the app's configuration so that comments are not displayed using the pop-up configuration and no comment field is specified.
Record the IDs of reporters
Reporter allows users to sign in using ArcGIS credentials. Reports that are submitted using ArcGIS accounts can be stamped with the associated ID. When configured, this allows users to review all the reports that have been submitted under the current account.
To configure this capability, add a text field to the feature layer for storing the account ID associated with each report. This field should be large — at least 50 characters — to accommodate the IDs. The name of this field should be the same across all features layers that will record these IDs. In the Reporter configuration panel, specify this field name in the appropriate parameter.
Symbolize a Reporter layer based on data values
Symbolizing features by an attribute can, at a glance, provide additional information about the report. For example, symbolizing based on report status can show users that their report has been acknowledged and the progress of work related to that report.
Each layer edited in Reporter can only have one editing template per layer so that the report submission process is kept as simple as possible. This means that, before publishing the layers, you shouldn't use symbol renderers such as unique value renderers that create multiple symbols for a layer. Despite this, there are two ways to specify symbols for different values:
- Use definition queries to break a single layer up into multiple layers based on data values. For example, to provide different symbols for sightings of different animals, use definition queries to create layers for each of the different types of animals and provide each layer with its own symbol. Each of these layers will appear individually in Reporter.
- Symbolize the layer in ArcGIS Online, Portal for ArcGIS, or ArcGIS Enterprise using a unique value renderer. Reporter uses the templates that were published with the layer, not the templates that are created in ArcGIS Online or Portal for ArcGIS so you can use the unique value renderers available with smart mapping to, for example, provide a different symbol for each of the status values. As these are all symbols on the same layer, the layer will only appear once in the app. In many cases, the field used for symbology should have either a default value or require a value so that the report will appear on the map as well as in the report list.
Track when reports are submitted
It can be valuable to know exactly when a report was submitted, and a user-supplied date is not always the best way to record this. To keep track of when each report 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 reports, it will stamp each report with the date it is created.
Record the location of reports
As well as having the geometry associated with the report, it can be helpful to know the search term used to find that report location, or even the address or coordinates of the location of the report. To record this information, include a fairly large text field (at least 100 characters) in your Reporter layer. When you configure your Crowdsource Reporter application, specify the name of this field in the location parameter.
For point layers, the app will first attempt to store a search location. If the search is not used or if a new location is selected on the map the app will attempt to find an address for the report location. If no address is found the coordinates of the location will be stored. For line and polygon features, the app will attempt the same reverse-geocode or coordinate-storing workflow using the first vertex of the drawn location. This location-storing functionality will only be available for layers with a field of the specified (case-sensitive) name.