Export features - do not export fields removed from within geoprocessing pane.

[wayfaringrob]

Following a spatial join, the workaround I mention here requires me to select at least one field from my join data.

Having done so, I have an extraneous field in my layer with an active spatial join. Seeking to make a permanent layer, I R click > Data > Export features.

Here, under Fields, I navigate down to the extra field (Loc_name in this case) and click the red X. I expect this to mean that this field will not appear when I click run.

Incorrect!

The field still appears in my output feature class. It also reappears when I go to reopen the tool from my GP history:

The same happens even if I click Edit and remove it from the pop-out window.

This is a suggestion to have the red X functionality remove the field from the output. I am unsure what it is doing currently, but it would be much more useful if that's what it did.

[wayfaringrob]

Another observation: if I hold my mouse click on Run, the field I removed reappears just before running. Is there some kind of apply/save button I'm missing here, or is this another oversight?

[wayfaringrob]

Yet another issue: renaming output fields does not work. The exported feature class does not include any of the field namings specified in the geoprocessing pane. Is this really where we're at with quality control? Very, very disappointing.

[Anthony]

this seems to be a recent change in the last 2 updates to ArcGIS Pro. I have the same issue where the export features geoprocess refuses to respect the configured fields. In my case I have a feature class and join it to a table and export it to overwrite an existing feature class, but when I try to delete fields before export it resets all the fields. I think this is a legitimate bug that needs to be addressed rather than its intended design (otherwise why give the option to remove a field if it won't actually remove it in the export)

[LarsArneson]

I'm still having this issue. It seems like something is broken.

I did a join, then exported the features to a new feature class. In the past this would have created a layer that act as if there were no longer a join, but all of the data would be included. Now it seems to cause issues with the exporting of features.

A clip of trying to delete fields before exporting.

[wayfaringrob]

@LarsArnesonI've been having nothing but problems with spatial joins ever since they redid the field mapping interface. Even if you remove the spatial join, you continue to get field output problems until you go to scratch.gdb and delete the old classes. Why this is necessary, I do not know, but it seems wrong to not even put a warning in there that you need to go delete the other scratch class too. This trips up a large number of students. If you don't do the join completely perfectly on the first attempt, expect issues. It's discouraging. Not great for learning. Not great for anybody.

[LarsArneson]

@wayfaringrob To me this is clearly a bug. It is something that used to work, now doesn't. There is an entire window that you can use to create edits while exporting and no matter how many times you make the edits you can literally watch them undo themselves within seconds. It was only after a couple tries that I realized nothing was changing. Very frustrating! @MichaelGrossman 

[DrewFlater]

Hi @wayfaringrob , @LarsArneson , @Anthony  I apologize that you ran into the defect you've described with the Export tools and field map control. 

I was not able to reproduce the problems that were described in the comments on this Idea, using the Export Features tool with Pro 3.4 or 3.5 Beta, using file geodatabase or feature service input. 

In earlier Pro release, a format specific problem related to the export tool field map was logged: https://support.esri.com/en-us/bug/export-features-in-arcgis-pro-does-not-support-editing-bug-000162... 

This defect was fixed in ArcGIS Pro 3.3, and backported to Pro 3.2.2.

Because this is a bug, I'm closing this idea. Please refer to the ArcGIS Ideas Submission Guidelines and Statuses: https://community.esri.com/t5/community-help-documents/arcgis-ideas-submission-guidelines-and-status... 

2. No bugs please. Idea Exchanges are not the right place to log software bugs or crashes.  Keep in mind that just because it isn’t the right fit as an Idea does not mean that we aren’t here to help.  Bugs and crashes should be logged with Technical Support.  If working in ArcGIS Desktop/ArcGIS Pro, crashes can be reported by sending an error report. 

If you are using a version after ArcGIS Pro 3.3 and still encountering a defect related to the field map, please use the link above to log a new Esri Support incident. Thank you!

[LarsArneson]

@DrewFlater I'm free for the next hour if you want to do a screenshare of the issue

[wayfaringrob]

@DrewFlater  if it were easy to report bugs, I'd gladly do so, but I do not have the requisite time nor My Esri access to do so. Even when I was in a position where I did, I stopped doing it due to the sheer incompetence of many of the support analysts. They would ask questions I had already answered and make me screen share to demonstrate issues I had already demonstrated. Or, they would call at all hours of the day and expect me to drop what I was doing to speak to them--again, in circles. If the only way to report issues to Esri has such a high barrier and is so wasteful of customer time, then it seems we are going to continue having many, many unreported and unresolved problems.