Make ‘create group with update capabilities’ a non-admin privilege

01-08-2021 12:50 PM
Status: Open
New Contributor III

Currently, creating groups with update capabilities is an administrative privilege that can be assigned to a custom role. We’ve enabled our entire university community (6000+ users) to have this privilege in order to facilitate collaborative editing of StoryMaps, Web Apps, Web Maps, etc., which is a common need in class assignments and research projects (see collaboration models for ArcGIS Online). Assigning this privilege to a custom role which we automatically grant to new users relieves us of the administrative burden of creating groups for everyone that would like to collaborate on content. 

There is, however, an unfortunate side effect of this being an administrative privilege. When connecting to the GIS in ArcGIS Notebooks, every user now gets a warning stating they are signed in with an administrator role, and to proceed with caution:

Screen Shot 2021-01-08 at 3.42.11 PM.png

This is misleading and causes confusion, as our users do not have the administrator role assigned to them. Given that users without this ‘create group with update capabilities’ can be members of shared update groups, and edit content therein, I’m not sure what distinguishes this as an administrative privilege. 

I’m proposing that ‘create a group with update capabilities’ be made a non-administrative privilege in order to more easily facilitate collaboration amongst users.


@GeriMiller I did put in a case with tech support....and they confirmed that this is expected behavior. I can get you the emails and put you in touch with the tech I worked with if you'd like.



Please do share the case/put in touch.   


Another reason for supporting this idea... 

Esri recommends creating a customized Publisher role in order to grant the Create with Update Capabilities privilege to those who will be creating Hub initiatives, so they can create initiative core teams:


You can create initiatives (site only and content group) if you are assigned the default Publisher role. To create an initiative with engagement features, you must have a custom role based on the default Publisher role, plus the following administrative privileges:

  • The Create with update capabilities (Groups) privilege allows you to create a core team. The update capability means that anyone who's a member of the group (core team members) can update any item shared to the group.
  • The Assign Members (Groups) privilege allows you to add members directly to the core team without sending an invitation to their email. This privilege is recommended because it enables you to immediately share content with new core team or supporting team members. The next time that they sign in to ArcGIS Hub, they can read their notifications to know which team they've been added to and see any items that have been shared with the group.
  • The Make groups available to public (Sharing) privilege allows you to create events.

@GeriMiller confirmed with the ESRI analyst I worked with that this behavior does indeed occur. When you create a custom role identical to publisher and add only the 'create with shared update' privilege the user can then see every service in the organization. Interestingly, I'm working in ArcGIS Enterprise 10.8.1 and she said this behavior doesn't occur in ArcGIS Online, go figure. Since the posts for this idea are for ArcGIS Online I created a new idea for ArcGIS Enterprise to make this privilege a non-admin privilege as well.


Within our third level academic institution we are having similar issues - as a Director of GIS Teaching and Learning in one of the Schools, I do not have the admin rights to set up groups which really affects opportunities for group work and for sharing data and maps with a certain cohort of students. We have enquired this with Esri, but have not being able to find a workable solution. Enabling group creation and management for advanced licenses such as Published should be a priority to facilitate workable iterations for group-based map and WebApp creation.

We currently have to request group creation to IT services, and even doing that, we have not been able to have a joint WebMap/WebApp that is editable by those registered as group members - has anyone had the same issue?

by Anonymous User

In our university research groups need to be able to work collaboratively on the same map / app. It is inefficient that only the university Esri administrator can set up a Share Update Group, this should be something that the person who sets up the Group can do themselves.

Firstly the administrator sets up a Shared Update Group and then invites the lead researcher to be the Group Manager (it is not possible to set up this lead researcher as Group Owner). Only the administrator can see the ‘Edit Sharing’ settings while creating the Shared Update Group. The administrator has to switch this edit sharing on in order to make the maps / apps editable within this Group. The Group Manager can then invite other researchers / collaborators to the Shared Update Group.

It is not at all clear why the Shared Update Group functionality rests with the administrator, as it would be much more efficient for Group Managers / Group Owners to be able to do this themselves.

Being able to share, edit, collaborate on maps and apps is at the heart of ArcGIS Online and it should be made as easy as possible to do this effectively.


Our current workaround at our educational institution, in case it's helpful to others:

Our organization has three main roles: Administrators, Publisher+Notebook (custom role adding Esri Notebook capabilities to the default Publisher role) and Publisher+Notebook+GroupUpdate (custom role adding Esri Notebook and Group Update capabilities to default Publisher role). Because Group Update is categorized as an admin privilege, the new member default is set to Publisher+Notebook. Once a day, a script is run to turn new user accounts to Publisher+Notebook+GroupUpdate. (note: we use enterprise login  with SAML, so as long as users have an authentic university ID, they are able to log in and create an account).

This removes a lot of the headaches for us, but it would be nice to just have the new member default set to include this capability. 


I support this and like others have created a custom role with this one privilege added. But it really shouldn't be needed.

Shared update should really be switchable at any time, rather than being set in stone @ group creation. Especially since having it turned on  can cause issues when trying to reassign ownership of items. I have had cases where group owners have asked for it to be turned off or on after the fact, and the only recourse is to create a new group with the requested setting.





I'll add that the ArcGIS Online documentation around shared update groups further complicates this issue. Even when you do grant all of your users a custom role that enables them to create shared update groups, then you still occasionally have users who don't realize they are empowered to do so. They send a request to the Administrators, as the documentation suggests they need to be an "Administrator" to create such groups.