Select to view content in your preferred language

Disconnect data storage/content from users

655
8
2 weeks ago
Status: Open
TjibbeWubbels
Regular Contributor

Summary:

ArcGIS Online’s user-level storage model creates risks for collaboration, continuity, and compliance—especially in high-turnover environments. It complicates access control, data ownership, and regulatory alignment (e.g. GDPR, NEN 3610, ISO 27001), making centralized governance and auditability difficult. I propose storing content on team/project level, independent of users.

 

Current Storage Mechanism: 

  • In ArcGIS Online/Enterprise, data, applications, dashboards, and other resources are stored at the individual Named User level. 
  • This means that all content is associated with specific individuals, which can create challenges in collaborative environments. 

 

Proposed Storage Mechanism:

  • Store data, applications, dashboards, and other resources in ArcGIS Online/Enterprise at team/project level. 
  • Access and permissions for specific individuals is set on team/project level.

 

Challenges Identified: 

In organizations such as AEC and others, this individual-centric storage model poses significant risks: 

  • Ownership Issues: Projects or teams should ideally own the data, rather than individuals. This is crucial as team members are often transient, moving between projects or leaving the organization. 
  • Data Reshuffling: When a team member departs, the data must be reorganized, leading to complications with applications and dashboards that rely on that data. 
  • Security Risks: The current model can expose sensitive information when individuals leave, as their associated data may not be properly managed or transferred. 
  • Backup and recovery challenges: Difficult to oversee if all relevant data has been included in a project or team backup.
  • No centralized oversight of data: content for a project or team is potentially spread over multiple users and hard to manage.
  • Dependency on individual users: If a dataset is tied to a specific user, others are dependent on this user to make changes to the content itself or the sharing level.

 

Comparison with Other Tools: 

  • Unlike government agencies and utilities, which typically have stable operators with consistent access needs, many organizations face high turnover rates. 

Tools like Microsoft Teams and SharePoint provide a more effective model for data storage: 

  • Group Ownership: Data is stored within teams or projects, allowing for shared access among members with appropriate permissions. 
  • Individual Ownership Path: Microsoft also allows individuals to own content through OneDrive, enabling them to share it with smaller groups as needed. 

 

Risks 

  • Loss of access: After a user leaves, content can no longer be accessed by the project or team (without administrator involvement and migrating of content)
  • Inconsistent sharing settings: Users may misconfigure sharing permissions, unintentionally exposing sensitive data or restricting access to others who need it. This is a security risk.
  • Overlooked data: Data is missed when sharing content to a client or when creating backups.
  • Locked content: if the user is absent, content tied to a user cannot be updated by other team members unless shared in a shared update group.
  • Audit trail gabs/regulatory compliance: user-level storage makes it harder to track who has access to data, to ensure data is deleted according to policy and to set up security by design (GDPR compliance). Consistent metadata and data models are more difficult to set up on team or project level (NEN3610 compliance). Centralized control over data, clear access policy and auditability and traceability are more challenging (ISO 27001)
8 Comments
CalvinHarmin

I whole-heartedly agree with this, and feel like this is more aligned with an 'Enterprise' type of environment.

Even though my organization is small, just a team of 2 pure-GIS workers, I like to consider a lot of our content 'Production', as it is essentially permanent resources used internally or by the public. I dislike the coordination necessary to consolidate 'Production' resources under a shared user account, in order to visualize/organize all the items into folders, which for me is critical for keeping our many hundreds of items from seeming like a complete mess, and makes management and review of all of our production resources easier. Especially auditing content naming conventions, and sharing settings, as you mentioned, which in my case need to be standardized for different use cases. 

CalvinHarmin

https://community.esri.com/t5/arcgis-online-ideas/allow-organization-and-or-groups-to-own-data-in/id... 

Jeez man... open for 6 years with 33 updoots and ESRI has not responded. I wish they would let it be Under Consideration at least. I think the idea deserves some dignity and can live out its years with the others of its kind that are consigned to oblivion 😢  Or Close it with an explanation/response. If the idea isn't feasible, I'd love to hear more from the AGOL team's theory for why, which could be insightful to better understand the limitations that they (and we) are working within.

BlairDeaverTRC

Great discussion topic!  One theme in the AEC industry that presents a unique challenge, is how to 'archive' project work from a GIS perspective. In the enterprise space this can be a challenge versus the traditional file-based project world. For example, I have heard from PMO staff that they want a way to 'archive' and record all data at project close from an archive perspective. This means, that all data is archived/snapshot at the point of archival.  AEC customers live by the project number, so having a better way to manage, collaborate, and archive work at the project level would be a huge improvement.  Thank you for your consideration.

AlistairFox2

This is a must for AEC Organisations to continue to use Enterprise and Online efficiently for delivering projects. Individual data ownership causes all sorts of headahes and complicates archiving procedures. This needs to start progressing into the Product pipeline and not stay as just another good idea. 

LeePowell_UU

Fantastic idea and a common implementation across many software vendors. This should be an offering within the ArcGIS System and made a priority.

Michael_Stead

I run into issues all the time where I need to manipulate data in a way that necessitates an administrator temporarily transferring ownership. My macro embedded spreadsheets using tokens only work on data that I "own". Typical business requirements restrict data to non-public user data where ownership can further complicates external access through scripting. More often than staffing changes, I run into issues when "owners" are in the field, off sick for a day, or on vacation. Group managed data with various "owners" creates all kinds of issues and I would love to see this capability added. 

MikeAppel1

I would love this to be the case (just like desktop GIS data and files). The design doesn't make sense in an environmental consulting industry when people work on a number of projects at once and multiple people work on the same project. As an Admin, I spend a ton of time transferring content around to different people. Then for heavy users I can't remove them from the system until all their content is changed to different people. This gets really difficult it they are in Shared Update groups or have offline maps turned on. It can take several days to just remove one user. Plus shared update groups don't seem to offer the full function of an owner, so even the project teams have to change owners frequently depending on who is working on the project that day.