Merge Layer list and Table list in Map Viewer

[DougBrowning]

I would like Layers and Tables to be in the same list in the Map Viewer TOC.  This would match Pro and other products.  Unlike Pro we should be able to have tables and layers intermixed vs tables always stuck at the bottom.  Plus tables can go in groups like layers. 

Use case is we have 3 set resources that fit nicely into groups and makes a long list look clean and nice.

But the tables list is just a long confusing list for the user that is in a totally different location.

Other big use case is Survey123 form data (or really any other set of related records).  A very common feature in 123 is repeats which are almost always related tables.  Now there is no way for us to group the layer and table data for the same form together.  So the user is forced to go find the table in a totally different spot.  With the removal of the Show Related Records button in the popup (please bring this back also) users struggle to find data that clearly goes together.  Forms with 2-3 repeats and nested repeats it gets even harder.

Being able to match the related structure would be even cooler!  Then the user can actually see visually how it all fits together.  This could be huge for all kinds of applications!  Like utilities for example.  Image the classic Telephone pole structure with related tables for all the equipment off that pole - would be so clear to the user.

Parent Layer

        Repeat table 1

              Nested Repeat table 1

        Repeat table 2

Sorry I thought I posted this years ago but instead have been talking to the teams directly.  I hear it is finally getting some movement!

thanks a lot

[PeterKnoop]

I too would like to see layers and tables combined into a single concept. There are already many places in the interface and documentation where "layers" refers to both layers and/or tables. And, whatever that solution ends up being, having it implemented in a uniform standard way across all Esri products, including Map Viewer and Pro.

It feels like the distinction between the layers and tables is perhaps a bit artificial, and is based on a characteristic of the data (i.e., spatial vs. non-spatial) that is less important to surface in an organizational representation than other characteristics of the data. I think it would be more helpful to enable ordering data in a meaningful way, such as organizationally, as in Doug's example of grouping related layers and tables together to help make visual sense of data schema in a single, hierarchical table of contents.