Export Features with Table Join - Field Mapping (v3.2)

[Andy_CS]

In Pro 3.2 -- When running the Export Features tool on a feature layer with a table join (validated 1-1) the field map is stating that the fields from the join table have two source fields and it looks like the source field is being duplicated in the dialog. Anyone else seeing this? Export works as expected (action is set to First) I just think it's a little odd.

In Pro 3.1 I just get one source field which is what I'm expecting.

[DuncanHornby]

I want to compliment this post with further evidence of the 3.2 field mapping in the Export Table tool as being buggy.  If the input is a Table or FeatureClass then if you change the output field type properties (e.g. the field length of a text field say from 8000 to 255) it remembers it. If the input is a Feature Layer or Table View then any property changes of a field in the field map are instantly forgotten when you OK the field mapping dialog. It makes building models in model builder impossible when you need to use the field mapping, this needs to be fixed fast.

[KyleKirkman1]

Concur 100%. I've been fighting for 2 days to deal with Modelbuilder export feature issues.

[JaronJensen7]

Anyone heard about a fix for this?  I am having the same issue in 3.2.1 with my model builder and the export feature class and export table tools in my model. They don't remember the field map, and the only way I can reset it so the fields show up is to run the model and then do the reset.

[Andy_CS]

This is separate to the original topic but as it happens I did experience the behaviour that @DuncanHornby and yourself are describing and raised it with ESRI - they have logged it as a bug under BUG-000163460 and
BUG-000162878 my issue was specifically with hosted feature layer inputs to the export features and export table tools.

The bugs are listed as fixed in 3.3, my solution was to revert back to 3.1. An alternate solution proposed by ESRI was to export the hosted feature layers to a local geodatabase first and then alter the field map.

I raised the duplicate field map inputs from the original topic with ESRI and was told the behaviour was expected, I did not pursue it any further.

[JaronJensen7]

I just got of a call with ESRI and I had the same issue of the input being a hosted feature layer. They said there were going to do some more digging, but it is good to know that it has already been raised. Thanks!

[DanPatterson]

I think what Duncan is saying, is that you should report this to Tech Support.

Issues that can be replicated with data and use-cases will be addressed.

[DanPatterson]

I don't see anything reported on the Tech Support site yet

Either no one reported it, or it is still under investigation.

Raising another issue may escalate the issue or provide first notice

[KyleKirkman1]

I created a ticket 2 weeks ago. An ESRI rep got hold of me and I'm not impressed with the answers- Take the input feature and edit in field data design and all outputs will contain / retain the correct field schema. 

That answer defeats one of the main benefits of Modelbuilder, the model processes take care of all manual processes.  ESRI's answer implies that Parameter of the model has to be fiddled with every time a new dataset is used.

A large chunk of my models deal with taking county centerline and address points, and crossing over to be used in Emergency Service softwares. Some sites I grab new data monthly, point the model at the new data (data fields don't change) and let it rip - historically, works every time! 

The 1st part of all models export the agency data into a new feature class where unnecessary fields are dropped and appropriate coordinate systems are assigned.  Most models have many processes and uses either export features, merge, spatial join, buffers, feature to point - all of which produce new feature class outputs where there is additional field edits/ modifications being accomplished within the model.   PRO 3.2.0, 3.2.1 just blows all field edits / modifications out the window in every new feature class.           ESRI attempted to contact me to experiment but after the original example I immediately reverted back to PRO 3.1.4 and will stay there for the time being.  

To state it again-  None of us should have to fiddle with field design with a new dataset in a repetitive workflow model process. I'm really upset over this. 

[DarylHochhalter]

This is still an issue, I recently upgraded to Pro 3.2 from 3.1. I've been using a python script retrieve features and table data from a REST service and export the updated results based on a joined layer to a feature class. fieldmappings don't work at all no matter what format I've tried. We are currently running Enterprise 11.0, I can run the same script on the server and it functions as expected. This is most certainly a bug. Also, the feature classes created with 3.2 from the REST service cannot be accessed in Arcmap 10.8.2, even though they reside in a File or Enterprise GeoDB where other feature classes can be accessed from Arcmap. This isn't the case if the feature classes are exported from another File or Enterprise GeoDB using Pro 3.2.