Survey123 'username' field is <Null>

TI · ‎01-08-2019

I have published a Survey123 with a field of type 'username' by which I was hoping to capture the ArcGIS Online user name of the account being used to submit the survey. Unfortunately, this is not working reliably. While most of the records in the feature service are submitted with the username as expected, a substantial number of them are submitted with <Null> (no value).

We are using Survey123 version 2.8.2 on iOS (and cannot upgrade any further for now due to our old iPads not being able to run a recent version of iOS), with ArcGIS Online as a proxy to a feature service on our local ArcGIS Server (not Portal), so that we can capture the data into our local SDE enterprise geodatabase.

In my limited testing, the <NULL> values are recorded when users are signed out (in Survey123) at the time they capture the survey data. Signing back in (in Survey123) to submit the data does not capture the username.

NB: The users are not deliberately signing out. They just get signed out by the system from time to time, without realising it.

My preference would be to be able to use the editor tracking fields for this (create user, last edit user), but in this case, the feature service is hosted on a local ArcGIS Server, not ArcGIS Online, and Survey123 submits to it via an ArcGIS Online proxy, because it cannot authenticate to our ArcGIS Server directly. So the create/edit user is always recorded as that of the saved credentials for this proxy feature service in ArcGIS Online.

Is there any reliable way to capture the username in this scenario?

UPDATE - I have just found these related topics:

Anonymous User · ‎03-11-2019

Hi Alessandro,

As I mentioned above, we are looking to improve the null username issue when opening survey when user was initially offline and then re-open from Drafts. A bug has been raised for this and we have an internal issue to track and try to improve this behaviour so that it can be automatically update when null. The public bug number is BUG-000113164 and I have also updated the internal issue with your comments and use case.

Phil.

AdminAccount2 · ‎08-08-2019

Has there been any improvements made to address this issue? As noted above there is no way to populate other fields in the form based on the username if the survey was started when offline. I've noticed in the latest version that users are required to login before submitting a survey, but the username field is still not being populated when the form is submitted. Any idea when this may be addressed? Thank you.

JamesTedrick · ‎08-09-2019

Hi Keith,

Currently, this issue has not yet been addressed.

JoshHabel · ‎08-16-2019

Any idea of when this bug will be addressed? I hope soon because this has completely ruled out using survey123 for editing work if you need to be able to limit editors to only specific work assigned to them. Does anyone have any workaround for such a scenario?

RachelS · ‎10-19-2020

Over a year on and there is still no fix for this. 25% of my records have the username as blank.

It's a pretty redundant field if you can depend on it to work reliably.

AdminAccount2 · ‎07-07-2021

This issue is causing major issues now as we have many more Survey123 users and this is happening more often. The username field is also being used to get the submitters email address from the SSO login and then process the submission through Integromat. If the user is not logged in, then no email address is available and the whole system falls apart.

Is there any news when this will be fixed? Hopefully ASAP!

Anonymous User · ‎07-07-2021

Hi @AdminAccount2,

Have you logged a support case with Esri Support? If so can you please provide the BUG number so we can take a look into the detailed information.

The details of your enterprise configuration, authentication methods, device etc will be key to resolving this issue.

Just an FYI - login information is cached and the app can be used offline and user is still signed in, provided at time of going offline they are still signed in. Problems can occur if during a check to remain logged in (token refresh) if that fails due to bad network, the user may be logged out unexpectantly, and need to sign in again on a valid network.

Regards,

Phil.

AdminAccount2 · ‎07-08-2021

Hi Phil,

Thanks for the reply. I have not logged a case with Support. The scenario you explained above is probably exactly what's happening. During a check to remain logged in (token refresh) ...the user is in the field without any valid network available so that check fails and they are logged out. They cannot sign in again since they are still in the field without a valid network connection. It's not feasible to ask the users to abandon their work in the field, drive to a location where they can access a network to sign in again, then return to the field to create a survey. That's not going to happen. I imagine this scenario is fairly common for people working in remote locations - in our case wind and solar farms in the middle of nowhere. If this is the case, how can this be resolved? Seems like a major flaw in the intended (disconnected) functionality of Survey123. If there was a way to control/adjust the token refresh requirement wouldn't that solve the issue?

Anonymous User · ‎07-08-2021

Hi @AdminAccount2,

The best way to avoid this unexpected sign out is to put the device into offline mode before going into the field. In this workflow, if you download the required surveys and additional data while online, ensure everything is there and ready to go, and then turn off network connections (WiFi, 4G, mobile data etc.). You can leave the GPS (location services enabled) if you need this for the location in the survey.

If you then go out into field in true offline mode, the user will still be signed in (in a cached mode) and the username field and other user based information will still be available and used in the survey. And becuase the app is offline, no checks will be done to keep the user signed in or to refresh token. Once the user has finished in the field, and is back to a location with a good network, they can enable the network and send all their surveys.

This is the best workaround whilst we continue to resolve this issue and make improvements to the way the user sign in, cached credentials and token refresh works with SSO environments.

Regards,

Phil.

AdminAccount2 · ‎07-26-2021

Thanks Phil. That would work for some people, but many of them would either forget to do that or not want to do that because they need to be connected for other reasons. The ONLY way to make this work reliably is to take the responsibility out of the users hands and force the issue programatically. We cannot rely on the field people to do this on a regular basis. In the office world it seems like a simple solution, but in the real world with hundreds of non-technical people using this app it's just not going to happen. Hopefully there will be a better solution soon.