Can't add new table to existing hosted feature layer through REST API

[AndreaGalligari]

Last year I published a hosted feature layer with 8 geometrical layers. This feature layer is being used to collect data from the field through dedicated webmaps.

Lately, there has been a need to add an extra table to the existing feature layer to accommodate changes in our project's requirements.

Researching online I found that there is no easy solution, unfortunately. It would have been useful to have a dedicated design tool to add layers/tables to existing feature layers.

The only thing I found is to Add to Definition through the REST Service Directory.

I then performed some tests. I aimed to get the JSON section of the table I want to add by publishing two versions of the same feature layer from ArcGIS Pro: One with the table (first feature layer), and one without the table (second feature layer). I then extracted the JSON definition from both sources and compared them on Notepad++. The differences started indeed at the end of the second feature layer as we can see by this snippet:

What I did then was to append the "Table" section of the JSON definition to the second one by ensuring that it was perfectly matching the first JSON. I only had to change the "tablename" argument to match with the second feature layer's name as follows:

I then went back to the REST Services Directory of the second feature layer and tried to use the "Add to Definition". What I replaced to the JSON definition was basically the exact definition of the first feature layer, so I was expecting for it to work, but unfortunately it did not and this error message was pulled:

Invalid definition for System.Collections.Generic.List`1[ESRI.ArcGIS.SDS.Metadata.LayerCoreInfo]
Exception has been thrown by the target of an invocation.

This functionatily is very important in the frame of content management to maintain data tidied and the only alternative I have is to create a new hosted feature layer just for the extra table I need.
Any help, tip or hope for a future improvement in this functionality would be appreciated.

[MobiusSnake]

I've done this before but I changed more than the table name value.  Unfortunately I didn't document exactly what I changed, and it was a while back, but I'd look at anything else that could be unique - like the ID value below your table name, index names, anything like that.

Is your new layer going to be a related layer, e.g. a repeat in Survey123?  If so you'll also need to add some relationship definitions to it.  I think this needs to be two additional operations, adding a relationship with an origin type to the source layer first, then adding a relationship with a destination type to the target layer.

Also, are you testing this on your live layer?  I'd recommend creating a new feature service using the original as a template and working through the process on it, I've made mistakes doing this kind of thing that turned out to be irreversible.

[AndreaGalligari]

This table will not be a related table, because it's a copy of another table we don't own, from which we will only perform append and update operations through Python scripting.

This test is also not on a live layer, I published two dummy layers to test this out, but it didn't work.