Hi @AhmedWaleed ,
Here is the process it is following if I understood your use case properly.
When you run the SF account aggregation, the account will be aggregated and the identity created with 00007124 (if you check the name attribute of the identity from debug, you will see name=“00007124,” which is important for correlation).
After an AD account has been created, you are updating the username in the SF application. And I believe you are not updating the identity attribute name. I think you are updating only the username attribute in the SF account, which is authoritative. That is the reason the correlation is not working out here. So for that, you have to update the native identity (name) of the identity ( the value will be changed. name=“Ahmed.waleed”). So, in the next AD account aggregation correlation works with the updated name value (it is important which attribute you are using for correlation in the AD application). Make sure you are using a username only for correlation.
So once correlation works and is correlated, then it won’t create an account separately. The identity attribute will work as the picking up of unique value, and the display attribute will work for creating with the name.
If you need more information related to the display attribute, the identity attribute and how correlation works, I have prepared a nice document, you can go through it. You will get more clarity.