Are there any examples of a good ArcGIS online/Portal organization?

Question

GIS at my organization is rapidly expanding beyond being something that just the GIS department is using. We have a rapidly growing AGOL footprint (soon to be portal within the next year), but AGOL org has historically been setup with just the GIS department in mind. No broader consideration given to departmental data and users outside of the GIS department. I'm looking to change that retroactively, but I'm having a hard time figuring out what a good organizational structure looks like. One area I've always struggled with AGOL is the lack of nested folders. My content page is just pure chaos, mostly because I'm not really sure how else I should be storing things. I'd love to have a folder for each department/project and organize further from there, but that isn't possible. So I'd love to get a peak into a "model" organization that is both easy to maintain and easy to find and share data through. That way when we move to Portal, I can start from a clean slate with a better system in mind. Thank you!

JonathanMcD · Answer

@MDB_GIS  What I've done, and of course there's a few ways to skin a cat and depending on size of your organisation, is the following;

Groups - Each service area or team have two main groups to themselves. One for all team/service members, another Editors' group for key data custodians or creators in that team. This means that a team/service can create and share their own data amongst themselves - especially important where you've got sensitive or operational data that you don't want the organisation to see. As an example, I have 130 Groups, so 65 teams/services setup each in their own space. This AGOL setup is mirrored in the way I did Portal too.

A typical service will see for example "Planning and Built Environment", "Planning and Built Environment (Editors' Group)" as their own.

Every member of the organisation belongs to an Organisation Group where I share all content elements from data to apps etc.. I have a couple of other groups to manage, by default, new members and other app elements.

Folders - as admin I have folders setup and named for likes of Organisational Maps, Instant Apps, Dashboards etc, then for data I have folders for each theme of data eg; environment, iot, flooding, roads, planning etc etc.. Typical folder being called "data - admin boundaries" or if I want to keep certain folders to the top "-=Public Maps and Apps=-"

Org Categories - setup to allow easier searching and part of how I manage our Open Data deployment, however, it's not really something that from a management piece I'm delving into often. I categories setup mirroring what I have for my data folders by theme.

Tags - like above just help with data searches in both the data catalogue and Open Data.

Member Categories - basically mirror the group setup, so a member is in a team/service category

Member Roles - Creators have the ability to share data to the team/service groups they belong to, but not to the organisation ,and not to the public. They also can't create their own groups - in our exploration of AGOL before going enterprise, I allowed this and it quickly got messy. If a service wants a public facing element, then they approach me and we discuss.

Admin account - my admin account owns all data and apps that are published to the Organisation. Sharing is kept as me the owner but shared to the Organisation Group. As I finally have the confidence in Data Custodians to truly look after their own organisational dataset, I will change ownership of that dataset to them, once due processes are in place.

Credits - I limit everyone to 5 credits, even my admin account I limit to 100. Saves having any mishaps where people try to geocode 50,000 address points in one go. Most users that would be looking to do analytics have deployed ArcPro.

Data Interoperability Tool (FME) is your friend - I use it nearly every day to run update processes, report outputs for service areas where they are carrying out inspections, risk matrices, or even just a simple run through of publishing a dataset.

MDB_GIS · Answer

This is good info. Thank you. Do you share all your layers from your named user AGOL account or do you have an AGOL admin account to share out organization wide data?

HarryPlendl · Answer

The first thing I recommend is creating groups for admin and management. Then department groups. For the content the Configure Categories has been extremely helpful in sorting out content that I want to quickly find. Categories are a little bit of work upfront but in day to day operations it will make a world of difference. The folders may ever give you the "nested" feel of the file explorer but with the filters the Tags feature should be able to clear it up. If you need even more refined organization you could make custom roles or users for the groups. Organize for each department to have a folder, group, category and tag. Categories can even have subcategories which might be the feature you have been missing in the folders constrained organization.

Folders > Groups > Categories> Subcategories > Tags > Sharing > Custom Member Roles

The model being suggested is to use all the available tools to organize your members. I recommend giving some agency to departments to manage their own groups and to train a 'super user' in those departments to aid in the content management.

Hopefully this is a start for getting the AGOL into the shape you desire.