In ArcGIS Velocity, both real-time and big data analytics can be configured to write output records to a hosted feature layer. As the creator and owner of an analytic, you can decide who has access to the data in these feature layers. This can be controlled through a combination of sharing and editing settings.
To determine who to share your feature layer with, and which editing properties to set, consider the questions below.
Who needs to edit the data?
In ArcGIS Velocity, real-time and big data analytics automatically facilitate edits made to output hosted feature layers. This is done as part of the analytic processing pipeline rather than manual editing that may traditionally be done by an editor user. This is not to say that user-based editor workflows cannot be performed. Consider both workflows when deciding who needs access to edit the data.
By default, the owner of an analytic and its output feature layer(s) can make edits to the layers even if editing is not enabled. This is useful if a layer happens to require infrequent changes outside the analytic. If you do not need to make the layer available for post-process editing by users in the organization, and you want the analytic to be the authoritative source for all layer edits, do not enable editing.
If you want other users in the organization to be able to edit data in a hosted feature layer created with ArcGIS Velocity, enable editing on the layer and share it with the appropriate group. Note that, when sharing the layer with a group or the organization, only those members who are assigned a role that includes editing privileges can edit the feature layer. A future release of ArcGIS Velocity will support public sharing of layers and by extension, anonymous access editing.
Do all users need to make the same type of edits?
Once a hosted feature layer is created by an analytic, you must decide what type of editing is allowed after you enable editing. With editing enabled, three options are available that allow users to control the exact type of editing necessary. The options are add, update, and delete. For example, you can configure a layer so editors can only update existing attributes but not add new records or delete old records. Likewise, you can configure a layer so editors can only add new records but not delete old records or update existing attributes.
If users editing the layer are doing the same type of edits, all you need is a single hosted feature layer with one setting. As the owner of an analytic, you still have full editing control on the layer no matter what editing settings has been configured for other users.
If different users need to perform different types of edit operations, a single hosted feature layer is not sufficient. To meet this need, create a hosted feature layer view from the hosted feature layer, enable different editing options on the view, and share the view with the appropriate group. You can create multiple views from a single hosted feature layer to meet different editing requirements if necessary.
What if you want some users to edit but not others?
Similar to when different editors need different levels of editing access, you can create hosted feature layer views to meet this need. You can enable editing on the hosted feature layer and share it with only the group or groups whose users need to edit the layer. Next, create a hosted feature layer view from the editable hosted feature layer but disable editing for the view. Share the view with the groups who need read-only access to the data. This is useful if you want the entire organization to view the features but only need a few organization users to edit it.
Do you need to track who edits the data?
You can enable editor tracking on a hosted feature layer when first configuring a Feature Layer (new) output. This adds fields to the layer to record the name of the user who creates a feature and when it was created, as well as fields to record who last edited a feature or its attributes and when it was edited. When an analytic is used to automatically facilitate edits to a hosted feature layer, the creator and editor username fields can be populated either from the analytic owner's username or from a field value in the incoming data.
When first configuring a Feature Layer (new) output and enabling editor tracking, the only option available for the creator/editor username is My username. This assumes the creator and editor username is the owner of the analytic. Once the Feature Layer (new) output is incorporated into an analytic such as to the output of a tool, you can edit the feature layer output to choose a string field for the creator/editor username. This assumes the creator and editor username is populated using the values from the streaming data.
Enabling editor tracking provides additional control over the types of queries and edits users can make to the data. For example, you can restrict editors to only edit the features they add to the layer or only allow editors to see the features they add. This is accomplished through ownership-based access control.
Do you need to restrict editing to a particular geographic area?
If you need to restrict editing to specific geographic areas, you can create hosted feature layer views. This is useful, for example, if a particular geographic area requires feature edits or is the only area you want other users to see. You can create a view, define an area of interest, and share it with a group whose users need to edit or view data in that area. Then create additional views for each additional area of interest required and share those views with the appropriate group(s). For more information, see Create hosted feature layer views.
Do you want to restrict editing to particular features or attributes?
For example, if you have a single hosted feature layer that contains driver and vehicle information updated in real-time, you can create views with the following definitions:
- Create one view for users that manage the drivers. Configure the view so only those fields that store driver information are available to those users.
- Create another view for users that manage vehicle information. Set a definition on the view that only makes available the fields containing the vehicle information and share the view with the group that manages vehicle information.
- Create another view for users that support driving operations. Set a definition on the view that makes available the location of each vehicle and other drive-time fields or attributes with a group composed of the operations staff.