Offline Area not supported if Webmap has duplicate layers

[AndreaGalligari]

I would like to enable the Offline Area to allow fieldworkers to work in remote areas. Unfortunately, the system doesn't allow me to enable it because of the way my Webmaps are set:

I have several layers that are duplicated because each copy has a different setting in terms of style, filters, pop-ups, forms, and labels. This is apparently not supported for Offline Area.
Other cases include a feature layer provided by my client (thus I don't own it) that has field names with more than 31 characters and other layers (specifically a Join View layer) provided by my client that don't have the sync enabled.
Are these going to be addressed for future releases? The Offline function would be a very useful tool for us since it often happens that our crews are in out-of-reach areas, so they are forced to collect the data with other tools and populate the forms when they are back in a reachable area.

Here are some screenshots of the issue on Field Map Designer

Thanks in advance for any help!

Regards,
Andrea

[MitchellGrafstein]

Not sure if you will get some developer feedback on this, but I believe I know at least the reason why there are some current limitations.

Every layer/table in a map has its own local Mobile Geodatabase (SQLite database) created when an offline area is created.  This offline mobile geodatabase also has an associated replica in AGOL or Portal.  The mobile geodatabase syncs with its replica.  Because of this, you cannot have multiple layers/tables that would be associated with the same local mobile geodatabase and AGOL/Portal replica. 

Sync is also required for this to work, since the GlobalID and editor/creator fields are required for this process to work as far as I can tell.

As far as the length of the field name is concerned, my guess is you would probably have to create some kind of replication or ETL/script to truncate the field name(s) in a repeatable manner and possibly have the aliases preserve the true field names.  This also might need to be the solution for the layers that you cannot control the sync on.  

Hopefully someone with some experience with the last part (replication between services) will come here and be able to assist if there is an easy/easier solution there.

I hope this helps.

[AndreaGalligari]

I can understand this from this point of view. It would be ideal if, by disabling the edit for each duplicate layer from the WebMap Designer, the Offline function would be available since only one copy for each layer would be editable.
Concerning the syncing, I may ask my client to enable it, but I don't know if Join View Layers have that option.

[MitchellGrafstein]

I agree that it would be convenient for layers that rely on the same source to be able to coexist in an offline map, but I have a feeling we are not going to see that anytime soon.

You would have to create a view for every layer that you have control over, then add those views to the map instead, so each layer/table in your map would be pointed to a different service.

Not sure about the Join View Layers, but as you are discussing in your other reply, I do have a feeling that a script will be required to move data between services.  The script could easily capture the layers that match, even if you have to truncate field names on your own end.   

You could attempt to create a new layer from the join/view layer service as a template.  You may also wish to create your own service as a link to the existing service, but I have a feeling you won't be able to necessarily trick it to sync that way.  At some point, the editor fields and the globalid field are going to have to exist in your own service.

There are also ways to have collaborations where services can sync from one org to another, but that could be a security issue depending on your orgs (and I have only seen it function once, and I believe it had some hiccups - that was also on Enterprise and not AGOL.)  

Where the data lives (AGOL or ArcGIS Enterprise) I am sure will also be important on whatever the final solution is here for you.

Hope this helps.

[MErikReedAugusta]

Another brute-force workaround: I see you mention you're somewhat restrained as this data is from & for a client.

Is the client directly-connected to the data you're collecting, or is there some breakpoint that you could put in the middle for processing?  Because in theory, you could make a "field" copy of the database on your side that has all those duplicated fields broken out into separate fields with shortened names.

Then, it's just a matter of writing up a relatively simple python script to read the data from those separate tables and merge them down into the "master" table that you'll be sending to the client.

It's far from ideal, since there are a number of potential pitfalls if your tables are highly self-interoperable, but it theoretically could be done.

[AndreaGalligari]

That layer "RMO Poles" is just a dataset that we need from our client for our operations, we don't write on top of it, but we need it to be always up-to-date. I can see the possibility through a Python script, but would there be problems since truncated field names will not match with the original ones?