Survey123 Inbox - Avoid overwriting data

122
4
04-25-2020 11:06 AM
JAVIERVARA_SANZ
Occasional Contributor II

In our scenario, two individuals are working from different locations, but responsible for tracking items in the inbox, retrieving information, and updating information as needed.

Is there any way in Survey123 to avoid the same record from being retrieved and submitted by two or more individuals? Filtering by user name won't be an option, since we won't to keep the number of Surveys published to a minimum. Ideally the inbox would auto-refresh on a periodic basis (setting), but this won't work in an offline scenario, so all I can come out with is the idea of versioning, where a record could be validated before the synchronization takes place. 

Workflow:

  • Initial record is submitted and flagged as "0"
  • Record is retrieved with the inbox in devices A and B
  • Record is selected and edited in device A and flagged as "1". Record is then updated and submitted, compared to record flagged as "0" in the server, validated ("1 > 0"), and synchronized. Record in flagged as "2" in the server.
  • Record is selected and edited in device B and flagged as "1", Record is then updated and submitted, compared to record flagged as "2" (previously updated and sync in device A), and not validated ("1 >/ 2"). Device B sync error message
Tags (2)
Reply
0 Kudos
4 Replies
Philip-Wilson
Esri Frequent Contributor

Hi Javier,

You can filter the Inbox using a where clause based on username, where the username is pulled from a field in the survey that has been assigned to them and matches their logged in username. This can be done without needing to create multiple surveys.

Regards,

Phil.

Reply
0 Kudos
JAVIERVARA_SANZ
Occasional Contributor II

Thanks for the suggestions Phillip. 

I understand how we could leverage assignments to users to resolve this. However, we'd like to avoid relying on an intermediary to do these assignments, but rather have the users handling requests on the fly.

Here is an example of what could happen:

  • Form A - User A1 edits record 1 and sets its status to 'scheduled'.
  • Form B - User B retrieves record 1 ('scheduled') from inbox and updates it to 'received'.
  • Form A - User A2 has not refreshed the inbox, so he pulls the original version of record 1 from the inbox, updates it to 'scheduled', and unintentionally overwrites entry from user B, so the record is no longer 'received' and back in user B inbox.

As I mention, our workflow can't rely on an individual to assign tasks, so we can't use the username in a where query clause. Also keep in mind this is an interactive environment where users that have access to Form A come and go and work in shifts, so the same record will need to be accessed by those on duty at any given time.

I hope this helps clarify.

Thanks.

Javier

Reply
0 Kudos
Philip-Wilson
Esri Frequent Contributor

Hi Javier,

Thanks for clarifying, that all makes sense. Unfortunately there is currently no easy way around this issue, as when the Inbox is refreshed, the surveys are downloaded to the device and stored locally in the sqlite database. Therefore if the user does not refresh the Inbox again before opening a survey, they may be using an old version of it. You need to ensure your training and workflow for your users advises them to refresh the Inbox whenever they are online and before they edit a survey.

However, you could try and use a JavaScript function in your survey, and have a field with validation or constraint, that queries the feature service online, and if it has been updated since the survey was downloaded (check to see if a value is different etc) you could alert the users by a note or making a constraint fail, that means they can not submit the survey.

JavaScript functions are currently a beta feature and you can find out more on the Early Adopter Community.

Regards,

Phil.

Reply
0 Kudos
JAVIERVARA_SANZ
Occasional Contributor II

Good afternoon Phillip.

I truly appreciate your detailed response, and agree with you 100% we'll need to handle this particular case scenario through training. Would this be something the development team would consider for future versions?

Meanwhile, we'll look into the option leverage JavaScript to validate entries. 

Thanks for everything.

Javier

Reply
0 Kudos