Feature Layer Views for non-hosted data

[ShelbyZelonisRoberson]

Hosted feature layer views in AGOL/Portal are great, but are there plans to allow these to be created on non-hosted feature layers (i.e., data that is registered with an enterprise geodatabase)? Yes, I could create my own views on the back end, but then I have to publish multiple layers. In some cases it would be easier to just make Views of them in my Portal like I can with hosted layers.

[ShelbyZelonisRoberson]

It depends - for the most common use case it would be 6 different views per feature service (one for each of our police districts/crime analysts) and each view would hide features. Most likely each analyst would create their own view of a countywide dataset that shows features for their district only, and there are use cases where they would also want their own symbology. This would allow them to only use/see a much smaller and more manageable subset of the full data but retain a near real-time version since it is registered with the EGDB. 

[JulieMikolajczyk3]

We have similar workflows to many of the use cases already listed. One use case is to apply different filters to the data after it is published (it's republished every six hours). We don't want to have to overwrite/republish five layers with definition queries when overwriting/republishing one and having several different views that "just work" does the same trick. Most of the data for this particular project is in an enterprise geodatabase using server services, but we have to publish this data to AGOL just to take advantage of hosted feature layer views.

[JustinRoberson]

Hi Thomas,

Thank you for the suggestion. I am aware that a map service can be used for some use cases. Unless I am missing something, I believe that any additional configuration of the map service layer (pop-ups, filters, etc.) are only saved in the web map in which it is being used. If I use a feature service, I am able to save the layer configuration at the item level. This allows many users to grab the feature layer item and add it to a map and it will already be configured in the Portal environment. If this is incorrect, please let me know.

I also know that the feature service needs to be shared with the same permissions as the underlying map service. So I am unsure if this could cause issues where I want the underlying map service to have a different level of security than the feature service.

But to echo some of the other comments, I think there is value in this process being more simplistic and easy for users that do not have a ton of in-depth enterprise GIS knowledge.

[DominicDoiron1]

This is something that would be of importance to us.  We have authoritative data hosted on our Enterprise Geo database that is used by non-GIS application.  These datasets are updated anywhere between 15 minutes to every month.  We want to be able to publish our data to ArcGIS Enterprise and give users the ability to create Views tailored for their needs without having to duplicate the data as Hosted Feature Services.  We are using Enterprise as a Self-Service platform for users who whats to do their own maps and analysis on authoritative data.  Right now a User that creates a map with our Feature Service (data in SDE) and applies a filter on it, this affects everyone accessing this particular layer.

[DamonNelton]

Been awhile since a comment on this topic. Anyone still following this thread got any updates. I'd like to be able to publish a reference non-hosted feature layer that is filtered by geographic space like you can in a portal hosted layer.

Thanks Damon

[JoyDRoberts]

^^What they all said. I have similar needs here at a large utility. I have data that is referenced from a database and that is edited by one, and only one, team.

Other teams/business units need some portion of that data, usually with fewer fields and definitely in a read-only state.

Creating Views like are available on hosted layers would seem to be the simple answer. 
Having to publish multiple versions of the same data with different editing permissions, def. queries and symbology seems inefficient for both the GIS team and the server bandwidth/resources.

[MatthewKelly_SP]

Need this from an operational point of view.