For assignments in the "Started" tab, a duplicate assignment is created after questionnaire upgrading


it was observed that after upgrading a questionnaire from a previous version, a new (duplicate) assignment will be loaded to devices for assignments in the “Started” tab. This means that there will be the old assignment in the “Started” tab, and a new duplicated (unwanted) upgraded assignment in the “Created new” tab". Not sure if this issue is been worked on, but it is still present at the moment.

The assignments that are synced with the tablets, but not completed are also upgraded. This does lead to duplicate assignments. We also face this problem, and have to manually delete the duplicate interviews.

It would be nice if the system is able to check for synced assignments and not upgrade them. Or delete the upgraded assignment on next sync if a completed interview is synced back from a tablet.

An assignment may not be in the “Started” tab. Only interviews are shown in the “Started” tab.

The reason for the issue is that the server doesn’t know whether an interview has been already started for a given assignment on the tablet. Correspondingly, two lines of behavior are possible:

  1. ignore all assignments, which have been already received to the tablets, during an upgrade; or
  2. upgrade all regardless of this status.

First was deemed not practical, since users keep on carelessly assigning bulk (hundreds of assignments) upfront (see, for example, here).

Hence the second behavior.

It is strange that you do get duplicate interviews. Not sure about the design of the survey, but most households are unlikely to respond to the same survey twice (and if they do, it could also mean that the interviewers do not introduce the survey properly to the respondents, limiting themselves to something like “We work for the government, and we need you to answer some questions”).

What you could do is to reassign the newly created (after an upgrade) assignments to the supervisors (you can do this with the API), then let them wait for the interviewers to synchronize, then doze the new assignments.

Clearly a periodic cleanup with the API could also be scheduled to eliminate the assignments created after update when an interview arrives based on the outdated assignment.

I agree that we should not get duplicates and these assignments should be ignored. But the field interviewers tend to ensure that everything is completed. They fill in the same information again, thinking that there must have been a problem with the last form. We understand the issues involved, but we find it hard to ensure that the forms are not duplicated.

I don’t understand why the first option is not practical. An assignment that has been already sent to the interviewer should not be duplicated.

A middle path may be to run a check during the next sync, and delete the duplicate assignments from tablet that haven’t been started or completed and delete the started and completed (on tablet) assignment from the server.

I agree it would be practical if the server could detect interviews in the “started” tab.

To a user - who does not know the inner workings of the software - it is not clear why there is a substantial difference between the “started” tab and the “completed” tab. E.g. why the server can check if an interview has been “completed”, but not if an interview has been “started”.

How would the server do it?

When synchronizing, checking both what’s in the “started” and “completed” tabs?

By the time the interviewer comes to synchronize it is too late. The server must already decide what to do. It can’t wait for days to complete that action. When it upgrades assignments it decides for each one whether to:

  • retain the original, OR
  • to close the original and create a new assignment

And it must do that at that moment and with the information available to the server at that moment.

I have a few suggestions:

  1. Retain original AND create a new assignment, and decide which one to keep on the next sync?
  2. Retain original and Mark it for upgrade on next sync. Only upgrade if assignment not started.

I do not understand the technological challenges with these methods, but logically this should work.

I still feel the easiest work around will be to not upgrade the assignments that have been sent to the tablet. The PAPI analogy would be that we have sent the interviewer with the physical forms (ver 1), any changes to the form will be (Ver 2) and will be applicable only to the forms given to the interviewer after he returns.

That would require to introduce some dependency/relationship between assignments, which is not existent in Survey Solutions, where they are independent one from another.
Moreover, what if the supervisors start reassigning the assignments in the meanwhile (before the sync?) Another interviewer will get the new assignment, complete it, then the first will finally sync…

Similar issues here.

Infinite assignments (size=-1) are a popular choice. They still need to be upgraded. Realistically all of them will be having some interviews.

Yes, I agree, 100%. That would be the safest solution. But when during the training we say “Do not assign all the assignments on day 1 to your field staff” everyone say “Yes, certainly” and then go home and assign all the assignments to the field staff on day 1. Needless to say they still want to update those assignments. (and the chances are higher specifically for these users, where there is mismanagement in the field, there are also design flaws in the questionnaire, hence the need to upgrade it often).

Think of it as a USB stick. You can use it in either of the two modes, but you can’t have both:

Same with assignments: if you assign assignments for the week, collect all interviews on Friday, upgrade on Saturday, you are good to distribute the assignments next Monday with out any worries. But if you hand out all of them, then Monday is not going to be pleasant.

At most, we could introduce the choices a la Windows selections above:

  • safe upgrade (ignoring the assignments received on tablets);
  • unsafe upgrade (current behavior).

This sounds interesting.

@sergiy This issue continues to be a pain when updating the questionnaire and upgrading assignments.

In our current survey, we have multiple interviewers with pre-loaded forms allotted to them. We allot all forms of a village to the interviewer visiting that village. So, at any given point of time there are always allotted forms to most interviewers.

It is almost impossible (without wasting man days) to ensure that everyone completes all allotted forms before upgrading assignments to newer version.

1 Like

Since the server cannot know whether an interview has been started–the server’s assignment status info is stale–could the Interviewer app resolve assignment updates? If no interview has started, Interviewer would replace old assignments with new ones. If an interview has been started, Interviewer would not update the assignment related to that interview.

Here are some practical issues for the interviewers:

  1. Waste their time. In larger surveys, they may not remember if they had filled a form for a person and will visit again only to realise that this interview was already completed.
  2. They will complete the second interview, just because it was allotted to them. They may not question the reason for duplication.
  3. They may send back the duplicated interview marked as could not visit or similar. This increases the effort in the back to trace these interviews and delete them. (We need a recycle bin for unwanted interviews)
  4. This confuses the interviewer. He now needs to be briefed about what to expect and what to do. This just creates friction in the process.

I feel that (at least for us) the issues arising from this duplication outweigh the benefits of upgrading all assignments as per server’s old state.

Although not upgrading synced assignments will be the easiest and acceptable fix, it would be really cool if the sync process could check if the synced assignment is started or not, and archive one of the two assignments.

This would solve all our problems!

1 Like

Just to jump in and say that I definitely feel @ashwinikalantri 's pain.

Also, this rings very true for my survey experiences:

While I don’t have the answer about what would be the best and/or easiest to implement solution, I definitely see duplicates arising from upgrading assignments as a perennial problem. (In fact, I’m sorting through this right now for a recently completed survey.)

1 Like