Symbology Not “Sticking” in ArcGIS Pro 3.3 When Using Joined Fields and Versioned Data

195
2
06-26-2025 08:47 AM
Labels (2)
KathrynWesson
Regular Contributor

A coworker is running into issues when creating new polygons in a feature class that's symbolized using unique values from two fields in a joined table. She accesses the data as a layer file through a traditional versioned connection and uses feature templates generated from that layer file to create the new features.

As I understand it, the template should automatically attribute the record and consequently apply the correct symbology based on the joined fields. However, after creating a new polygon, the feature appears with the default symbol instead of the correct symbology, even after reconciling and posting. The attribute values are correct in the table, but the symbology doesn’t update unless she removes the layer file from the map, re-adds it, re-applies the table join, then rebuilds the feature templates. It's such a lengthy process to do every time she creates a new feature.

This issue was rare in earlier versions of ArcGIS Pro, but since our upgrade to version 3.3, it’s become a daily problem. It seems like the symbology engine no longer recognizes joined attributes immediately after feature creation, and needs a full refresh to align the rendering.

In short:

- The layer is symbolized using joined fields.

- The data is traditionally versioned in an enterprise geodatabase.

- Templates are configured to auto-symbolize new features.

- Joined fields drive symbology directly.

- After saving edits and reconciling/posting, symbology still defaults to the generic symbol, despite correct attributes.

Has anyone else seen this behavior in 3.3? Is it a known issue or bug? Would love to hear if others have found a workaround or logged it with Esri Support.

0 Kudos
2 Replies
JonM32
by
Frequent Contributor

@KathrynWesson I've had issues with joins before with all sorts of things - symbology to field calculator issues.

I view joins as a temporary thing to do on a layer (view results or transfer information to other fields), but when you want work with it long term, creating an exported final copy of the layer works best in my experience. 

Jon
KathrynWesson
Regular Contributor

@JonM32, agreed! That's solid advice in general. Unfortunately, I was hoping for a solution that does not involve changing the live source dataset (via a new field) or exporting to a static copy. Appreciate the suggestion, though!