Wanted: Creative Solution to Working with Related Data

[AmyRoust]

Posting here as a last-ditch attempt to find a creative solution to my issue.

I created a query layer that joins point geometry to a related table. (The relationship class is 1:M, but there is only one related record of this type associated with the point.)

Symbology and labeling in the map depend on the data in the related table. I published this query layer as a view-only feature service to Portal version 11.5. No problem.

Now, I need it to participate in our distributed collaboration to ArcGIS Online (as a copy, not a reference). When I Enable sync and try to publish from Pro, I get the error message "Dataset ... is not configured for or cannot be used with the Sync capability: Publishing a non-versioned dataset without archiving enabled by reference." This is logical: the system has no way to check for changes in the data without either versioning or archiving. Both the point feature class and the table have archiving enabled, but that doesn't come through in a query layer.

So then I thought I'd try to use Arcade to get the information from the related table, but FeatureSet functions don't work in labeling or symbology profiles. Again, this is logical: first, the data would have to be queried, then it would have to be rendered. Translation: s-l-o-w performance.

Can anyone think of another workaround that I am missing? The labeling is what really gets me - I'd really like to have a label so that the user doesn't have to click on the point to find out what is there.

[Robert_LeClair]

Because distributed collaboration (copy) relies on the service being sync-enabled, a query layer (especially one that includes a join to a related table) generally won’t qualify—even if the underlying feature class/table have archiving—since the published dataset isn’t an archive-enabled/replica-trackable dataset in the way sync requires. That’s why you hit: “non-versioned dataset without archiving enabled by reference”.

The practical workaround is to remove the runtime join from the sync-enabled layer and materialize the attributes you need for symbology/labels into the feature class that will be published.

Try this - denormalize into a published “label/symbol” feature class

1. Create a new point feature class (in your enterprise geodatabase) that includes the point geometry plus the one related record’s fields you need for labeling/symbology (or a calculated “LabelText” field).
2. Populate it from your source using a scheduled process (geoprocessing/Python) that:
   • joins/aggregates the related table to one row per point (since you effectively have 1:1 for this subtype), and
   • writes/updates the point feature class fields.
3. Enable archiving (and ensure GlobalIDs exist) on this materialized feature class (and any included tables, if applicable).
4. Publish that layer with Enable sync, then use it in collaboration copy and for labeling.

This avoids Arcade FeatureSet calls during drawing and keeps labeling fast.