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:
Proposed Storage Mechanism:
Challenges Identified:
In organizations such as AEC and others, this individual-centric storage model poses significant risks:
Comparison with Other Tools:
Tools like Microsoft Teams and SharePoint provide a more effective model for data storage:
Risks
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.
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.
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.
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.
Fantastic idea and a common implementation across many software vendors. This should be an offering within the ArcGIS System and made a priority.
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.