nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Retain field ordering when portal layer is added to a map

Debert

When pulling a Hosted Feature Layer through the AGOL Portal, the field order is not retained. This makes quality control and updating attributes more difficult, as users become accustomed to the familiar order of fields in the attribute table (e.g., beginning, middle, end). When the field order is lost, it significantly slows down the workflow and increases the potential for errors if extra attention is not paid.

I’ve tried multiple workflows to preserve the field order schema, but none have been successful.

An enhancement that retains field order when a layer is removed from a map would be extremely beneficial for our workflows.

A bug has been logged BUG-000172553.

I hope you'll consider this.

Trouver plus de publications taguées avec

Map Authoring

Under Consideration

Status: Under Consideration

Réponses

williamscraigm

That issue ended up being converted to an enhancement ENH-000172553 which was then closed with the public explanation:

"This is the expected behavior. Fields cannot be permanently reordered at the database level.
https://support.esri.com/en-us/knowledge-base/how-to-permanently-reorder-fields-in-a-feature-class-us-000025984"

Is something being lost in the communication here? If the desire is to save the field re-order, you can use a layer file for layer level re-ordering without altering schema.

Debert

Hi @CraigWilliams, thanks for attempting to clarify.

I'm still a bit confused as I previously attempted the workflow to permanently order fields using Export Features and they didn't stick. Again, the issue remains when pulling the Hosted Feature Layer through the AGOL Portal for edits- field ordering rearranges. Support also tested this and saw the same behavior.

As far as saving as an .lyrx, I've previously attempted that workflow as well. It's my understanding that the .lyrx is a symbology properties file and has nothing to do with the field ordering.

I'm really not sure what I'm missing here.

KoryKramer

@Debert when I pull a hosted feature service from ArcGIS Online into Pro, field order is the same (Online on top, Pro on bottom in the image below).

You can save a layer file that hides and re-orders fields. When added to a map, it's still referencing the same hosted feature service but honors the layer definition in the lyrx.

Debert

@KoryKramer I see the image on the top has field ordering of [Year, Fire Name], while the image on the bottom has field ordering of [Fire Name, Year]. And, while having only 2 fields doesn't cause as much of an issue, that field ordering is not the same.

Add 10-15 custom attribute fields, plus 28 GNSS receiver metadata fields, and you have a jumbled mess of attribute fields. People get use to seeing certain fields in certain orders, which also helps with editing.

I don't understand why field ordering is even a thing, if it doesn't retain the order you set them in.

Debert

@CraigWilliams .LYRX files work for symbology. However, they do not apply to scaling or field ordering. I've tested this on my own and also with Esri support. They also saw field ordering not retained and thus an enhancement was logged.

Debert

@CraigWilliams Thank you for considering this 👏

Rejoindre la conversation

Connectez-vous pour publier, suivre du contenu, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.