When administrators configure a unique Moodle profile field, they expect robust enforcement of data integrity. This prevents multiple users from sharing the same identifier. However, situations can arise where duplicate values appear in a field explicitly marked as unique, leading to confusion and operational issues.
This unexpected behavior can compromise user management, break integrations, and complicate reporting. Diagnosing it is less about Moodle failing than about knowing where the value actually came from, which is one of the common challenges with Moodle that surfaces only once a site carries real user volume. In this article, we’ll explain how Moodle handles unique profile fields, why duplicates still appear, and the strategy for auditing and cleaning your user data.
I recently migrated my site to Mindfield from another host, and the experience couldn’t have been better. Mindfield kept working until they were certain that my site was operating as well as it was before, and they even helped clean up a few issues to improve my site’s performance – issues my prior host never mentioned. I also found Mindfield’s communication to be excellent. Before the migration, they prepared me for what to expect, and during the migration they kept me well-informed.
Jim Benedek
review Source: Google Reviews
Outline
- Understanding Moodle’s Unique Profile Field Feature
- Diagnosing Duplicate Entry Paths: Manual vs. Bulk Upload
- Unmasking Hidden Duplicates: Common Causes and Checks
- Auditing and Cleaning Existing Duplicate Profile Data
- Ensuring Data Integrity with Mindfield Consulting
- Frequently Asked Questions (FAQs)
Understanding Moodle’s Unique Profile Field Feature
Moodle lets administrators extend user profiles with custom fields that capture information the core account record does not hold, such as student IDs, employee numbers, or external system identifiers. The control that matters for this discussion is Should the data be unique?, a Yes/No menu that sits under Common settings when you create or edit a custom field under Site administration > Users > Accounts > User profile fields.
Set to Yes, it instructs Moodle to check every save against the values already stored for that field and to block anything that collides. That check is the entire mechanism, so any diagnosis starts with confirming the flag is actually set on the field you think it is.
Configuring a Custom Profile Field for Uniqueness
Two details in the interface catch people out often enough to be worth naming up front. The field type is chosen from the Create a new profile field menu before the settings dialogue opens, so uniqueness is a decision you make after the type is already locked in. And the Short name carries its own separate uniqueness rule, which has nothing to do with the values users enter. Administrators regularly assume a field is protected because the short name was accepted, when the data setting was never switched on.
Consequently, the first diagnostic move is not a database query. It is opening the field definition and reading what Should the data be unique? is actually set to, because a field that was cloned, imported, or created in a hurry frequently never had the flag enabled at all.
Where the Constraint Applies and Where It Does Not
Uniqueness is available only on custom profile fields. Standard fields such as first name and last name cannot be constrained this way, and email uniqueness is handled separately by Moodle’s account rules. That distinction matters because organisations often assume a policy applies site-wide when it only ever covered one custom field.
It also matters that values reach that field by more than one route. Administrators type them, CSV uploads write them in bulk, and external platforms push them in through the Moodle Web API or an enrolment integration. Each route hits Moodle’s validation at a different point, so identifying the route a suspect value arrived by is usually what narrows the investigation fastest.
Diagnosing Duplicate Entry Paths: Manual vs. Bulk Upload
Moodle applies the same constraint through different machinery depending on how the data arrives. Understanding those pathways is what turns a vague “the field allowed duplicates” report into something testable.
Manual User Creation and Editing
When an administrator creates or edits a user through the web interface, the check runs in real time against the values already stored for that field. A collision stops the save and returns an error stating that the value has already been used, so the person entering the data finds out immediately rather than discovering it in a report months later.
This is also the cleanest way to test a suspect field. Attempt to save a value you know exists on another account: if the save goes through, you have learned something concrete about the field’s configuration rather than speculating about the platform.
Bulk User Upload via CSV
Bulk upload, under Site administration > Users > Accounts > Upload users, processes many records at once and therefore checks in two directions. It compares each incoming value against what is already stored for existing users, and it compares the rows in the file against each other, which catches a file that duplicates a value internally before any of it is written.
Either kind of collision is flagged on the upload preview screen with the message This value has already been used. followed by the field name in brackets. Testing this on a Moodle 5.2 site with a two-row CSV sharing one identifier produced exactly that against the second row, while the first row passed cleanly.
The preview in that test showed the flagged row and nothing else: no upload settings, and no button to continue. There is no conflict-resolution option to reach for, because the conflict is a hard barrier rather than a warning you can acknowledge. The path forward is to correct the file, or the value already held against the existing user, and upload again.
Unmasking Hidden Duplicates: Common Causes and Checks
Most reported duplicates are not a bypass of Moodle’s logic. They are two values that look identical to a human and are genuinely different to the database, which is why the constraint let both through without complaint.
Invisible Characters and Trailing Whitespace
A trailing space, a non-breaking space, or a stray tab makes a string distinct even though nothing on screen suggests it. Values exported from a student information system or an HR platform and passed through a spreadsheet are the usual carriers, since neither the export nor the spreadsheet gives any visual signal that the character is there.
The practical implication is that eyeballing the data proves nothing. Any audit worth running has to compare values after trimming and normalising them, rather than comparing what the screen displays.
Collation, Case Sensitivity, and the MDL-87515 Report
Moodle’s uniqueness check ultimately relies on how the database compares strings. Under a case-insensitive collation, ‘studentID123’ and ‘StudentID123’ are the same value and the second one is rejected; under a case-sensitive one, both can coexist. When duplicates differ only by case, collation is the first thing to confirm with whoever administers the database, and it is worth confirming rather than changing, since altering collation affects the whole site and is not a step to take casually.
There is also an open tracker report, MDL-87515, describing an intermittent failure of the uniqueness check during user uploads. It is worth knowing about, but it is unconfirmed, the reporter describes it as intermittent, community members have been unable to reproduce it consistently on Moodle 5.1.4 and later, and it carries no known workaround. It is not established behavior that the check is missing, so treat it as the last explanation to reach for rather than the first.
Auditing and Cleaning Existing Duplicate Profile Data
Once you accept that duplicates exist, the work splits cleanly in two: find every affected record, then decide which account keeps the value. Take a full database backup before either, using the same backup and migration strategies for Moodle you would apply before any structural change.
Auditing With Read Access to the Database
Custom field values live in mdl_user_info_data, keyed by fieldid to the definition in mdl_user_info_field. Because the values are keyed to the field’s internal id rather than its display name, the audit starts by resolving your field through its shortname in the definition table, then grouping the stored data values for that id to expose anything appearing more than once.
Two refinements make the results usable. Joining back to mdl_user on userid turns a list of repeated values into a list of named accounts, which is what someone actually has to act on. And repeating the grouping against a trimmed, case-folded copy of the data column surfaces the near-duplicates that a plain comparison misses, which is exactly the whitespace and collation category described above.
Cleaning Through the Interface, Not the Database
Deciding which record keeps the value is a business question, not a technical one, and it usually needs someone who owns the data to answer it. Once that is settled, make the corrections through each user’s profile in Moodle rather than with direct SQL updates. Editing through the interface fires Moodle’s own validation, so the replacement value is checked as you save it, whereas writing straight to mdl_user_info_data bypasses that logic and can quietly introduce the next inconsistency.
Finally, cleaning is only durable if the source is fixed too. Where identifiers originate upstream, the same rule that governs any project integrating Moodle with CRMs and HR platforms applies: the source system has to guarantee uniqueness before the data reaches Moodle, otherwise the same duplicates return on the next sync.
Ensuring Data Integrity with Mindfield Consulting
Duplicate values in a unique profile field are rarely just a Moodle question. They sit across user provisioning, database configuration, and whatever external system feeds your identifiers, and the wrong correction can spread the problem instead of ending it. Mindfield Consulting’s Moodle specialists diagnose the root cause, clean the affected records safely, and close the gap upstream so the duplicates stop coming back.
Frequently Asked Questions (FAQs)
This article may contain conceptual illustrations to help support the article content.
