I have a map that I have created and uploaded to AGOL that will have an office user input for the first third of the fields in a given layer. I created a survey123 form from the existing feature service of the map that was created, and when I try to submit a response on the web app, it fails to send and gives me this error:
Failed to submit.
In the map side, I have a GlobalID, and I have a text field called LeakID. It almost looks like when I try to send a survey, it is for some reason trying to put the GlobalID in the LeakID field. The leakID column only has a field length of 20, so I would understand why I am getting the error, but I don't understand why the survey is trying to put a value in for LeakID anyhow. Can anyone tell me what is going on here? This seemed like it would be a pretty easy process, but I have been fighting with this for a while now.
Thanks,
Damon
I wonder if that is the relationship class and it is trying to fill that in for you. I think if you dont have the normal parentglobalid in there it will try and use whatever relate you do have.
Just a guess without seeing the form.
My map has one feature and 3 related tables, and they are related by this leak ID. I don't often mess with survey123, but I tries to put a globalID field in the form so that maybe it would utilize that instead of the LeakID field, but survey123 has that as a reserved name. Not really sure how to proceed with whatever is going on with it.
Can you share the XLSForm? Will help significantly
Update: I just deleted the relationship classes between the feature and the 3 tables. The survey works now, but I need the relationships to be there. I cannot use the standard GlobalID to GUID relationship as this causes a problem down the line with calculated fields in my field maps. The problem seems to be tied to the relationship classes however. Does this help anyone see what is going on?
Thanks
There is no repeats in this form so not sure why it is trying to add anything really.
I do see you have State in there - there green is telling you that is a reserved work and it can break SQLLite. Start by fixing that. You also use it as a list name not sure on that.
Is Gas Leak a layer that is a child? You pass in a key though right? It could be autofilling for you. Can we see a screen shot of the service.
Weird one.
There would be repeats in the form, but I delete them out. I only leave the pertinent questions that the survey123 user would need. There are a lot more attributes that the field employees will use, but they will interact with that in Field Maps. I will fix the State field name. Didn't think about that. Gas leak is the parent, and the leakID is the key for the child tables. The leak ID actually will get calculated in field maps through a sequence function. It is actually deleted in this form now.
I'll give a bit more background on what we are trying to accomplish here. There is a leak map, that will show all of our gas leaks in field maps. But if our office personnel get a leak call, they need to be able to enter that and it show up on the leak map for the guys to go investigate. So the guys can open the map and add their own discovered leaks through field maps, or the office personnel can add a leak through survey123 desktop as they don't have company phones, but computers instead. It's a bit of a dual purpose map. Upon creation of a gas leak in survey123, the leak doesn't have an ID yet. But once the user in the field opens it in field maps, it assigns itself the next id in the sequence, and then the three tables are keyed off of that value.
Another update on the base problem I'm having, when I deleted the relationships to the three tables, everything worked as it should. Then I extended the field length of LeakID to 50 instead of 20, and I stopped getting the truncate error, but it is putting a GlobalID esque value in the leak ID field in field maps. I'm hoping my calculated field can just clear that value out, and overwrite it with it's own actual ID and all should work okay. Still would like to know why it is putting a value in the LeakID field though. I don't want that at all.
Oh ok so it is field maps adding the key that makes a lot more sense. Field Maps auto adds the key to any child since otherwise it is an orphan. This is by design and you cant change that.
Why dont you just pass the main ID of say the value all the way down? Why have a LeakID at all? It is because you have mutlilevel repeats? It seems like you have a Top level Parent that is say an address or value then you have either 3 forms linked to that parent or you have a Parent form and child forms I cant tell.
You could have the initial Leak form created in 123 vs Field Maps is one idea. Use a URL link that fills out or passes the ID in. That way you skip Field Maps and its auto stuff.
You can also create 2 relates and Field Maps will only populate the first one based on my testing.
Also test if you go into settings and turn off Filtered Related types the blue + sign will then let you create children directly vs via the popup from the parent. This may trick it to leave the field blank or calc it. But I am not sure it will let you calc a globalid like that. I suggest using non globalid keys anyway. Otherwise if you ever move this to a SDE or something it all breaks.
Or if it is all parent and form children skip the LeakID and just use you asset id directly from parent to each form.
Hard to tell for sure without seeing it but hope these ideas help.
The portion of the field maps layer that the survey123 form is contributing to is the Gas Leak layer, which is the parent. Then there are three tables that are children: Leak Monitor, Leak Repair and Final Review. The children are not tied in with the survey123. And leak ID is not a renamed globalID field. It is a text field. There is an actual globalID field in the field maps, leakID is just a text field. It shouldn't be auto-populating I wouldn't think. I would say that I would carry the auto-generated ID through, but the leaks created in the field maps side would not be able to create that same type of value.