I have a hosted layer participating in a collaboration. Because of the collaboration workflow, standard Editor Tracking is not suitable for our business requirements, so we use a simple Arcade expression in a form field to record the logged-in user
GetUser($layer).fullName
This is about as simple as a form calculation can get. It doesn't query another layer, use related records, perform spatial analysis, or use any FeatureSet functions.
As soon as this expression is present in the form, Map Viewer displays the warning:
"This form uses functions that limit attribute editing to 50 features."
If more than 50 features are selected for editing, the workflow becomes restricted.
Through testing, I found that:
- Removing the field containing the GetUser() expression removes the warning.
- Re-adding the expression immediately brings the warning back.
- No FeatureSetByName(), Filter(), Intersects(), or other expensive functions are involved.
- The only function being used is GetUser($layer).fullName.
The warning suggests that complex feature queries are responsible for the limitation, but in this case the only logic is retrieving the currently authenticated user.
From a user perspective this makes little sense. A basic audit field that records who performed an update should not disable practical bulk-editing workflows.
What makes this particularly frustrating is the wider state of bulk editing within the ArcGIS platform.
For years, users relied on Web AppBuilder workflows for efficient editing. Web AppBuilder is now retired/no longer supported, and organizations have been pushed toward Experience Builder and Map Viewer.
However, the replacement workflows have taken an extremely long time to mature. Bulk editing functionality has arrived slowly, and even now relatively simple form configurations can introduce unexpected restrictions.
The result is that we have:
- A modern editing experience that still limits common operational workflows.
- A warning message that implies complex calculations when the form is only retrieving the current user.
- Large-scale editing scenarios that become impractical.
- Organizations forced off legacy applications without equivalent editing capabilities being fully mature.
In local government and utility environments, updating 50 features at a time is not unusual. Recording the responsible editor is also not unusual.
Users should not have to choose between:
- Capturing who performed an edit, or
- Performing efficient bulk updates.
Both should be possible without compromise.
At present, a form containing nothing more than GetUser($layer).fullName can trigger a restriction that materially affects editing productivity. For organizations managing large datasets, that simply doesn't feel fit for purpose.
