Preventing duplicate records on the app

Our group just started using and I’m finding we’re getting a number of duplicate records. I think it is because most of our sites have more than one trap and the user loses track of whether they have entered data for a particular trap.

If they reopen the trap record page, it appears that the trap has not been serviced because it shows the default (species None, Trap status Still set bait bad, etc.) and they think they haven’t entered the data for that trap.

I know the header section shows the date of the last entry for that trap and it will say the entry was updated a few moments ago, but it appears that some users are not seeing this.

I wonder if it would be better if the main body of the trap record showed the previously entered data. That way, it would be very clear that the trap data had been entered. Perhaps hold the previously entered data in the app for an hour and then revert back to the defaults?

In addition, if a user submits a new entry for a trap within this time period, this should be considered an update - not a new entry.

Sometimes duplicates can arise because if using the app with data on bit poor connection I believe the app keeps pushing the data out sometimes not realizing it has been received. It is difficult to verify this but it is the only explanation I have for single trap locations receiving the same duplicate entries. My work around is to try and use the app offline until back home for an upload. Andrew

Thanks Andrew,
How do you use the app offline?

Make sure you open it at home with wifi or in a strong cell reception area. That will download the tiles and trap location info. Then when heading into the field turn off wifi and cell (or use airplane mode). Andrew

Thanks Andrew. This is a good workaround, however, I’d prefer include a unique ID for each trap record uploaded to the server from the app. That way they could recognise a duplicate record uploaded to the server and stop creating duplicate records.

@Makara_Peak, @scalder101, just for clarity the app does two things:

  1. Uses a unique commit ID per record. If this ID is attempted again it is rejected.

  2. As of v5 it asks for confirmation if a second record is attempted on any given day.

It shouldn’t be possible to unknowingly add duplicates. We get a number of queries about this which once we look into them tend to be people getting used to the system or adding second records if they have made a mistake in the first (records should be corrected via the logs "view online’ option.)

If you think duplicates are still getting through please let us know with examples and app version.

There is certainly room for discussion about displaying pending record logs at the bottom of the record forms.

Ngā mihi,

1 Like

Thanks Andy,
That ought to address the scenarios that both Andrew and I describe. I’ll add more detailed information if it turns out to be more than just user error.

Just a comment about correcting records (via the logs/view online path) - this is really unintuitive. I believe a much better option would be to hold and display the last trap record in the trap record page for a period of time (say a day). If someone resubmitted this data (either with or without changes) then you could confirm with the user whether this was a new entry or a modification to the existing entry.

Just a thought,

1 Like