Duplicate variable names do not create errors

Hi there !

I met a important issue. In XLSForms syntax, you can have for example a group having the same name as a variable and this is not problematic generally speaking, but Kobo sees it as problematic. This means that when you import an XLS form, duplicate names do not give you an error message, but Kobo automatically renames one of the names adding “001” to it. I understand that Kobo might have technical issues with a group and a name having the same name (although the Kobo Excel Analyser made available on the platform sees this as a prerequisite for some features, which is therefore inconsistent…), but the minimum would be to have an error message either refusing the form as there are duplicate names or else informing the user on import that his variables have been renamed. And when you submit data and export results, variable names has been modify without notice it to the user.


I am using KOBO Humanitarian response & ODK Collect v1.22.4.

Thank you for taking this into account :slight_smile:

Hi @chloelaborde,

Could you share the xlsform so that we could look over it. Thank you!

hey !

Sorry only saw your message today.
Here is an example form:
test.xlsx (38.1 KB)

Thank you :slight_smile:

Hi @chloelaborde,

Kindly please be informed that when a user uploads an xlsform with a typo error (say as shown in the image below, where the name laku is not unique):


The system automatically fixes the same as shown in the image below (where one of the duplicates is automatically renamed and then marks under original name under the $given_name column):


You could test the same by the following xlsform:

test_typo.xlsx (26.3 KB)

Steps to test:

  • Upload the xlsform shared in this post.
  • Deploy (you should be able to deploy in the system).
  • Download the xlsform and you should see the fix made by the system.

Have a great day!

Hi @Kal_Lam,

Thank you for this trick to check if Kobo automatically renamed duplicates. But the problem is precisely this : that KOBO renames automatically variables names.

You do not always know, or think, you gave common names so you are not going to download your XLSForm from KOBO once you upload it. The idea we had was to avoid KOBO to rename automatically by having an error message or a message saying that there were duplicates variable names in the form. It will allows the user to check his form himself and to modify it. It will avoid mistake in later analysis and data management.

I hope your will understand this request,


Hi @chloelaborde
Just out of curiosity, have you tried testing your form on say ODK to see if the behaviour is replicated? Normally when you forsee that you are going to have such kind of potential errors, the most sensible approach would be to look at your form kindly. My approach would be to control for this at the excel by enabling conditional formating for duplicates on names. This enables me to flag these before I can even test the form.

In essence, knowing that the behaviour on Kobo is to rename, one should take caution to avoid uploading a form with duplicates. I would also suggest that you post this as suggestion for future development if you strongly feel that it should be incorporated as you had indicated.



Hi @stephanealoo,

Thank you for your answer. Yes of course we test forms on ODK before.
Agree, I posted it as a suggestion first, in “improvement”, as it’s not really an issue. It was an idea to make KOBO more user-friendly as I am not sure all people who are going to use KOBO know this. It was not me who classified it in “user-support” and looks like I can not change the category by myself so I will post it again in suggestions.

Kind regards,

Hi, and sorry to resurrect this older issue, but in case of duplicate variable names, as I understand the first one will retain the original name (say X), while subsequently encountered duplicates will be renamed to, say X_001, X_002, etc. This has been illustrated by @Kal_Lam in the above.

What will be the action if X was used in any conditions? How would the reference be renamed? Or always remain the same value?

Consider a practical example:
I have two groups: situation 5 years ago and situation at present, where the cost of an item is asked. I then have a logic that asks optional questions when price>110. Suppose that the variable price was named so in both groups, when the described renaming occurs, will the second condition (following the second variable price, now turned price_001)

  • remain as price>110? or
  • get turned to price_001>110?
  • or anything else, perhaps?

In other words, how does the engine resolve collisions in variable names mentioned in logical conditions (or calculations of derived variables)?

I’d agree to @chloelaborde that duplicates should not be permitted globally anywhere in the questionnaire, regardless of whether they occur in the same group or in different ones.

Stephanealoo has recommended turning on conditional formatting to alert about duplicates in Excel. This advice can only be followed by those experienced users that are aware of the problem. Yet for the novice users, it is not obvious.

Regards, Telia

Welcome to the community, @tejapa6888! Please be informed that the variable name under the name column will only be renamed (if you check the same in the XLSForm). Anything outside that does not get changed (i.e. the names used in the relevant column, calculation column, or even in the constraint column does not get changed. You will need to check them manually and change them accordingly. Thus the best approach would be to check the XLSForm through this online validator.

1 Like

Dear @Kal_Lam thank you very much for explaining that in case of encountering duplicates in the ‘name’ column Kobo only renames the duplicate entries, and not any references to them.

Could you please also comment on the following that Chloelaborde has written earlier:

does “one of them” mean specifically the second (and further) occurrence(s)? Or, perhaps, groups have priority over questions, etc? Or is it resolved randomly? (I do not like randomness/uncertainty in such things).

Thank you.

Hi @tejapa6888

This follows the logical order, where subsequent ones are renamed.


1 Like