In ArcGIS Online For Organizations, how does one publish a hosted feature service that is shared with Everyone for viewing, while restricting editing to specific users or groups, and different kinds of editing for different groups?

In the help at the end of Editor permissions for feature services under Configuring multiple tiers of access it says

If you need to support multiple tiers of users, each requiring different operations, the recommended approach is to create one service for each level of user. For example, you could create a Professors service that might have all operations allowed. Along with that, you could create a less-privileged Students service with only Create, Query, and Upload operations allowed.

Which is great, that's what I need to do. However what is left out is how to reconcile the multiple Feature Services so that when the Professors create new features the Students see the new records, and vice versa.

The web browser management Create Service wizard allows you to use one feature service as a source for a new one, but only the data model is used (symbol definitions, field names & types, etc.) while the actual features are left behind, the new service is blank. This is the intended behaviour.

  • are you wanting it in the same web map? If you don't care about having more than one map. Each feature service also contains a map service one map with the feature service and one with the map service = editing control.
    – Brad Nesom
    Apr 12, 2013 at 17:43
  • @brad, no they don't need to be in the same map. However a Feature Service needs to be shared to be included in a web map, and once that happens people can bypass the map and go straight to the Feature Service irregardless of what share settings are set in the Web Map Service. Apr 12, 2013 at 17:51

4 Answers 4


After 2015-Jul-14

The situation is much improved. The organisation admin can create a group with Members can update items permission. This removes the need for shared login credentials and/or giving all editors organisation-wide admin privileges*, while also making group permissions answer** viable for public maps.

The new recommended practice is:

  • Disable editing entirely on the hosted feature service
  • As organisation admin: create an Editors group and grant the new “Members can update” permission, populate as needed. (Must be a new group, created after July 2015).
  • In daily use the editors use “Add layer to map with editing enabled” from item details page to override the read-only flag.

For full details see See Enable colleagues to update your maps and apps in the ArcGIS Blog and Best practices for using layers in maps in online help.


I harbour some reservation as the underlying security model doesn't appear to have changed, the feature service itself does not have a concept of authorized user or group. I believe there is still room for problems, but at least the surface area is greatly reduced and the possibility of accidental and mere curiosity driven data damage is removed.

Also please note existing services using the old methods are still vulnerable. In my testing yesterday I easily discovered unwittingly exposed feature services simply by searching arcgis.com for "edit feature service layer".

Prior to 2015 July

We had an extended conversation with some Esri Canada folks about this in Feb 2015. There is no secure method to govern simultaneous edit and read-only privilege roles in ArcGIS Online (at present). The best one can do is obscure the location of the editable service, as per Brad and Bmearns answers here, and then enable Track Editor. This would be followed with periodic scheduled reviews of the records and removal of those not made by someone authorized to do so.

An additional (small, weak) protective measure can to be add a filter to the web map to only display records where Creator is not {one space} (is not blank doesn't work). This only affects that web map. People bypassing the web map and accessing the feature service directly see everything.

If a secured and editable feature service is needed, you need to run your own ArcGIS Server somewhere else with sharing and editing locked down as needed, and then a read-only service exposed to ArcGIS Online.

This does allow utilizing the massive uptime, content distribution network caching, cpu/memory scaling, and so on of the ArcGIS Online infrastructure for widespread public read only consumption with edit access on a more meagrely apportioned and less costly machine. You are not going to get both in one place, with ArcGIS Online.

update, 2015-May-27: added Filter by Creator tip


I have set up groups.
One group is an edit group. In that group the editable map (with feature service) is shared.
The group is private and I invite only the editors to it.
Another group is for non-editors and I invite other members to it.
In that group my map service (non-editable) webmap is shared.
It works a bit like assigning permissions and roles.

  • This isn't effective as the edit/non-edit permissions are controlled at the group level. Anybody can bypass your groups and go straight to the edit-enabled feature service. In effect they create their own group that has whatever permissions they like. The underlying feature service is either open or closed, without any gradation between. See Ben Mearn's answer and commentary. May 7, 2015 at 15:41
  • then they aren't a contractor anymore because they are fired. Also they don't have an ioda of access on the service without the webmap.
    – Brad Nesom
    May 7, 2015 at 16:03
  • Can't fire someone who doesn't work for you. I added a feature to Ben's edit-restricted group from a personal public account, essentially it's an anonymous edit. I didn't need or use his webmap to do it. May 7, 2015 at 16:06
  • I can fire a contractor. All my groups are not public, all my data is not public, There are no globally shared services. You can't edit my webmap. I don't even tell contractor there is a webmap. "I" provide ios login info and control username password. so they make an edit, I punt their user.
    – Brad Nesom
    May 7, 2015 at 16:19
  • If the feature service is not open to public at all, then the issue I describe doesn't apply. However if the FS is displayed in a public map, any public map, and at the same time the FS is edit-enabled for anyone at all, then anonymous users can create/edit/delete data in the FS with minimal effort. In the case where the FS is never displayed in any fashion outside the authorized group, the data can still be edited anonymously, but the effort to discover the fs-ID in order to get to it is non-trivial. The door is changed from concealed to hidden, but it isn't locked. May 7, 2015 at 17:58

(edited 5/7/15)

Not ideal, but achieves collaborative editing and public viewing/not editing.

  1. make editors administrators under the organization
  2. make layer non-editable but share publicly
  3. administrators can "add as editable layer" for web admin and do disconnected/syncronized editing on Desktop

I was not able to recreate the correct permissions using roles, but this will work for us, since the number of editors is small and I trust them.

Feature service properties (editing disabled) Add with editing enabled menu

Something like what Brad suggested worked for me

  1. Sign into account with publisher permissions
  2. My Content > Add Item > From my computer > (check) Publish this file as a feature layer
  3. My Content > [Feature Layer] > Edit > (check) Enable editing and allow editors to ...
  4. My Content > [Feature Layer] > Share > Everyone
  5. My Content > [Feature Layer] > Add layer to [new] map
  6. On the map > share with everyone, disable editing on layer if it is enabled for some reason, save, publish through web application with share if desired
  7. Groups > Create group, add users to have edit permissions to group
  8. My Content > [Feature Layer] > Add layer to [new] map with editing enabled
  9. Share this map with the group just created for editors
  • A person moderately knowledgeable about how Arcgis Online services work, or even just willing to spend a lot of time pushing buttons and following links, can still go direct to the globally shared editable feature service (exposed in step 4) from their own map, which they have full control over. The procedure outlined here makes it inconvenient to get to an editable place but it doesn't forbid it. It provides a measure of protection, but it is not secure. Apr 2, 2015 at 19:10
  • Matt, check out my feature service at udel.maps.arcgis.com/home/… . On an account that isn't in the group with an editable layer, I'm not able to view or edit this. When I add that account back to the group I am able to view/edit again. The web application built from this feature service is at: udel.maps.arcgis.com/apps/webappviewer/… ... this may be a case where functionality has changed via subsequent updates?
    – Ben Mearns
    Apr 3, 2015 at 12:45
  • I'm interested in following through on this, please ping me at [email protected]. I confirm that attempting to view item details of the FS link above fails with 404 not found, ditto for "Buildings" and "Parking" layers from with the app. I'd like to go over the details of your configuration as compared to mine (screenshot etc.). Thanks! May 1, 2015 at 23:00
  • Found a way in. Look at "Buildings" feature service. There's a new record with NAME=Fake Building made by matt, to the north east off Old Paper Mill road. i.imgur.com/hi03EqU.png. Is this feature service supposed to locked from public editing? May 1, 2015 at 23:26
  • and here's a screenshot in your own app: i.imgur.com/ROeNA48.png May 1, 2015 at 23:29

The new recommended practice described by matt wilkie works fine for users in the group with the "members can update" permission if they only need to update data in the AGOL map viewer using the "Add layer to map with editing enabled" capability. However, I want the users in this group to be able to update the data using ArcGIS Collector. Edit permissions do not persist after opening the hosted feature layer in the AGOL map viewer with editing enabled and saving the map. The map can be shared with the group using the "Share > Access and update capabilities" feature in the My Content screen. But it won't show up in Collector for members of the group to access because the update capability is not saved as part of the map.

  • 1
    Welcome to GIS SE! As a new user be sure to take the Tour which describes the focussed Q&A format that we use here. I've read your answer a few times and it appears to me that you are trying to present a slightly different problem in the area reserved for direct answers to the original question. Normally, any "answer" that does that is simply deleted, but in this case I am not quite certain so I'll leave this here to give others the chance to review it too.
    – PolyGeo
    Nov 11, 2015 at 22:53
  • I also am reading this as a slightly different problem. Please update the language if this is not the case.
    – MaryBeth
    Nov 12, 2015 at 3:26
  • Apologies for misunderstanding the format, and thanks for pointing me to the tour. I thought by comment was relevant because in my mind it shouldn't make a difference whether you're editing in the AGOL map viewer vs. Collector. The permissions should be consistent. But I'll take that up with Esri support and/or the ArcGIS Ideas site. For those like me who've come upon this question here for the same reason I did, it seems that if you want a feature service to be edited by one group in Collector and viewed by others, you have to revert to configuring multiple tiers of access.
    – Neil Curri
    Nov 12, 2015 at 14:22
  • Feel free to delete my "answer" and subsequent comment if you don't think they're relevant.
    – Neil Curri
    Nov 12, 2015 at 14:23
  • Thanks for your contribution @Neil. I agree the administration should be the same regardless of what avenue is used to edit, but for obscure reasons it isn't apparently. Your comment is on topic, but adds a dimension which I think is best served by opening a new question along the lines of "How to have public viewers and private editors with ArcGIS Collector?", and reference this question so people understand it is not really a duplicate. Nov 12, 2015 at 22:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.