How to handle DUPLICATE_USERNAME error while performing deployment

by Sudipta Deb | May 22, 2015 | Apex, change set, deployment, dev 501, duplicate, error, test class, username | 0 comments


Recently, while doing deployment through change set, I faced an issue –
System.DmlException: Insert failed. First exception on row 0; first error: DUPLICATE_USERNAME, Duplicate Username.
Another user has already selected this username.
Please select another.: [Username]”


The username used in test classes were definitely unique, but still my test classes were failing with the below error message. After spending some quite amount of time, I have understood the problem. So thought of putting this in my blog hoping that it may help someone in future.

So here it goes –
Error message –
System.DmlException: Insert failed. First exception on row 0; first error: DUPLICATE_USERNAME, Duplicate Username.
Another user has already selected this username.
Please select another.: [Username]”


Reason –
Usernames are always shared across instances, but not across environments. It means if a user is having username as test@test.com in any sandbox, then this same username you can’t use in any other sandbox instances (CS*), but you can user the same username in production sandboxes (NA*, EU*, AP*). 

Uniqueness is always checked during deployment when tests are run. So an insert from test class will also fail if the username is already registered in another org in the same environments. So we need to make sure the uniqueness in maintained in test classes.

Resolution –
To be 100% sure that the username used in test classes are unique, you should follow the below approach to define the username –

    String orgId = UserInfo.getOrganizationId();
    String dateString = String.valueof(Datetime.now()).replace(‘ ‘,”).replace(‘:’,”).replace(‘-‘,”);
    Integer randomInt = Integer.valueOf(math.rint(math.random()*1000000));
    String uniqueName = orgId + dateString + randomInt;


Below is the link which you can check. Link

Written by

Related Posts

New Apex Method | Extracting Picklist Values Based on Record Type Inside Apex

New Apex Method | Extracting Picklist Values Based on Record Type Inside Apex

For years, Salesforce developers have faced a common challenge: programmatically retrieving picklist values that are specific to a certain Record Type directly within Apex. The “solutions” often involved either complex SOQL queries against metadata, relying on the UI API (with its associated callout limits and serialization overhead), or maintaining clunky custom metadata/settings.

Good news, Technical Potpourri readers! The Salesforce Spring ’26 release is bringing a game-changer that will significantly simplify your Apex code and improve performance: native Apex methods to filter picklist values by Record Type!

read more...
Apex Cursor and Its Advantages Over Batch Processing

Apex Cursor and Its Advantages Over Batch Processing

Struggling with large datasets and SOQL governor limits in Salesforce? In this video, I will dive deep into Apex Cursors, the powerful new feature that revolutionizes how we process millions of records.

Apex Cursors allow developers to navigate through query results in manageable chunks within a single transaction or across Queueable jobs. In this video, I will show you the correct way to implement Apex Cursor and also when this is an exception, how to handle that and perform retry.

read more...

0 Comments

Leave a Reply