Crowdsourcing is a method of using individual users to keep your data up to date. This is relatively common practice in databases of businesses where keeping address, phone and contact details up to date can be a challenge for the database owner. Crowdsourcing seeks to alleviate this burden by allowing users to identify, claim and edit locations with appropriate notifications and approvals.

Crowdsourcing is an add-on feature. Please contact MetaLocator staff to receive more information on how to upgrade. Once enabled, a number of new features will be enabled. This tutorial will walk you through the process of creating a crowdsourced business directory.

Under Results, then List, click Add Field. Then choose "Claim". This link allows the user to request to claim a given location in your database. In the example below, we have updated the link text to read "Edit" and also included an edit icon next to the link:

The placement, text and style of this link is up to you. Some users place this edit link on the Detail pane as shown below:

Once an edit link is in place, users can request to claim locations in your database. However, we must construct the form they will see once they are approved to edit.

The edit link has some dynamic behavior as follows.

When a user adds or edits a location, you can choose which fields the user can control. For example, if you do not want the user to edit the location name, it can be removed from the form.

Adding fields to the crowdsourcing form is similar to manipulating the search form or lead form in MetaLocator.

Under Crowdsourcing, click Add Field, and choose the fields required for your form. Commonly required fields are already included in the form default setup. Drag and drop form fields and update individual field settings as required to create your form.

Ensure you enable any fields in the crowdsourcing form as "Visitor Form". This effectively grants crowdsourcing users permissions to access the field when clicking Save.

Claiming an existing location doesn't account for when users want to submit a new profile to your database. For this an "Add Location" link can be inserted into the display. This displays as a Plus icon as shown below:

Enable the "Add Location" link under Crowdsourcing Settings as shown:

The tooltip can be translated by modifying the LOCATOR_ADD_LOCATION language constant.

Enable the "Login" link similarly under Crowdsourcing Settings as shown:

The login tooltip can be translated by modifying the LOCATOR_LOGIN and LOCATOR_LOGOUT language constants.

Back-end v.s. Front-end Editing
Your crowdsourcing users can manage locations entirely from your Website using the locator (front-end editing) or via the MetaLocator control panel (back-end editing). Front end edits are preferable when your crowdsourcing users are managing one or two locations. Back-end edits can be preferable when users have access to many records, and they may need access to bulk edit tools. The back end experience is similar to the MetaLocator administrative control panel minus a majority of features:

In front-end editing, the user interacts with the Interface on your website only, and never sees MetaLocator branding or the control panel (a.k.a. the back-end).

When creating links to your website, the system needs to know what page the Interface is installed on, so that it can create links for login, choose password and so forth correctly. Provide the full URL of the page where the Interface is installed in the Host Page setting shown below:

If the link to your Website changes based on the language of the end user, MetaLocator supports the dynamic replacement of the language code in this setting.
​

For example, if your Website is https://customer.example.com/us/en for English speakers in the US and https://customer.example.com/ca/fr for French speakers in Canada, you can specify the link as

https://customer.example.com/{{language}}/{{region}}

and MetaLocator will insert the language and region based on the user's preference as recorded when the user was created.

If this Host Page link is not provided, the system will link directly to the Interface preview, which should not be used in a production context with real users.

As users request accounts and access to edit certain locations, this triggers administrative approvals. New users must have new accounts approved, and each request to edit a location must also be approved. This allows users to "own" and manage multiple locations. The flowchart below describes the approval process beginning from the top left, where an anonymous visitor clicks the Edit link, hoping to edit a location.

Enterprise users have access to content versioning controls. These also provide the features necessary to stage changes from crowdsourcing users, allowing their changes to be held in a pending status for review by an administrator before publishing. Without staging, once the user has access to modify a location, they can do so at any time. An Administrative notification of each change is generated, allowing an admin to review the recently published content.

When content is staged, the following workflow applies to managing, approving and rejecting staged changes.

If a location record already contains the requesting user's email address in the email field and this Interface option is enabled, the Claim will be automatically approved, requiring no administrative intervention. The user will immediately receive either a link to choose a password (if no account exists), or access to the location with no need to approve access required by administrators.

As an administrator, you will receive various notifications based on the flow of user requests and content edits. Crowdsourcing notifications go only to the account owner. These notifications are as follows:

Click the "Review Request" button and you will be taken to the MetaLocator User Manager.

Toggle the Enabled button to grant or revoke access to the user.

When the user is Enabled, an email is sent to the requesting user to choose a password. The subject and body of this email are controlled by language constants LOCATOR_CLAIM_EMAIL_PASSWORD_RESET_SUBJECT and LOCATOR_CLAIM_EMAIL_PASSWORD_RESET_BODY respectively.

The user must also receive access to edit a location. Toggle the access requests to approve the user to access one or more locations.

Once the user has chosen a password and they have been granted access to one or more locations, they may begin making changes. When changes are made, they are reflected immediately or staged based on the "Stage Changes" setting described above. In either case, and Administrator will receive a notification as shown below. The language file for this email subject and body are LOCATOR_CLAIM_EMAIL_ADMIN_LOCATION_UPDATE_SUBJECT and LOCATOR_CLAIM_EMAIL_ADMIN_LOCATION_UPDATE_BODY respectively.

Click on "Review Request" to be taken to the location record that was modified.

If changes are not staged revisions are not saved. Without staged changes, the record is directly modified and the record should be reviewed for content if necessary. Generally you should stage changes if you do not trust the users making changes.

If changes are staged, they will be available by clicking here:

Clicking Pending Revisions will show a list of all changes, including a history of their access. They are sorted by date, most recent first.

Click View to see the changes. The resulting display shows a side-by-side comparison of the currently active record, compared to any changes posed by this revision. If there are multiple pending revisions shown as "New", work your way up from the lowest "New" version and approve or reject as needed until all changes have been assimilated.

Click Reject to reject the changes.

Click Approve to accept the changes from a given revision.

Users can be approved for access to multiple locations. Only one user can access a location record at a time, though multiple users can request access to the same location. If multiple users are approved for the same location, only the most recently approved user can modify the location. Under Access requests for a given user, MetaLocator lists any potential conflicts in access. In the below example, we show an extreme case where access has been granted to two users, shown with the Red icon. This situation should be avoided by not enabling the access request when the Red warning is shown. The Yellow warning icons simply indicate that multiple users have requested access to this same location, and when granting access, those other users may need to be considered.

When creating a crowdsourced database, sometimes an email campaign is involved to request that users create a profile. In those cases, the email campaign should include a link to "Sign up today" or similar call to action. The link should be constructed as shown below:

Notice the special "?ml___ml_trigger_registration=1" parameter. This triggers the "Claim new location" dialog. When the user provides an email and "reason", the user account is created and flagged as disabled. The user is then immediately redirected to the Crowdsourcing form to add a location.

The title of the "Claim new location" can be modified in the active language file under the LOCATOR_CLAIM_NEW_LOCATION language constant.

When registering to claim a location, the default display requests the requesting user's email address and a message as shown below:

This form can be customized to include additional user attributes which enable the collection of details regarding the user requesting access during registration such as name, phone or any custom field. These details should not be confused with location-level information. These are attributes of the users, not the locations to which they have access.

Up to 40 custom user fields can be provided. An example custom field is shown below:

For dropdown lists, checkboxes and other more complex controls, the Field Template must be modified manually using the same technique as custom Lead Form controls.

Custom User Field data is then visible in the User Manager as shown below.

The custom fields are also included in the User Export.

To test the user experience, you must do so as a logged-out user, in order to experience as the end user would. To do this, you can save any Interface changes and log out.

As an anonymous user, you can now test the experience. You must, however, use a secondary email address (other than your MetaLocator account). We commonly use the "plus" trick in internal testing. For example, if your email address is tester@example.com, you can commonly receive email at tester+anything@example.com. E.g. tester+1@example.com, tester+2@example.com, and so forth. These will be treated as separate accounts in MetaLocator but the email notifications will be delivered to your inbox. When testing in this way, sometimes it is helpful to use a completely separate browser while impersonating a different role. For example, login to MetaLocator as an administrator using Chrome, but browse the website and request to claim a location using FireFox.