hi team today I'll give you a walkover on how we can make changes in one of the script include files to make resolve the user user in the subscription table using different fields that is present in the user table so we'll try to cover it using this following scenario where we have the following user in the user table with user ID as test. user email as test. user example.com with first and last name as T user so out of as for the out of the box logic we try to uh resolve the user the user using the user principal name and the way we do it is currently we try to match the user principal name first with the email and as you can see here we have a direct match so this will resolve to this particular user but in case if this does not match then we try to resolve it using the user ID or the internal field name user name so in this first scenario since there is a direct match with the email this will get resolved as test user but in the second scenario where we have test at example.com so it does not satisfy the first criteria that is it is not matching with the email and it also does not match with the username which is test. user but here we will just have the test so in this case we will try to see how we can modify our code and try to resolve this using the first name field that will'll have on the user user datable so let's go ahead and create uh on a on a service no instance and try to replicate the scenario so first I'll go ahead and create this particular user right so now we have the user created so let's go to the subscription table so as of now there is no subscription present so what I'll do is I'll try to execute a background query uh to create the user exactly how we create it uh during the subscription pull specifically in this case for the Microsoft 365 and what this code will do it's basically go ahead and create the test user uh for Microsoft 365 Enterprise E5 and for a Microsoft 365 profile integration and the idea is since there is a direct match with the uh email so the user should get tool so the subscription record is created and as we can see the user has been resolved since there is a direct match now we'll try to create the second scenario which we were discussing regarding test at example.com so modify that so now that there is a no direct match with neither the email nor the user ID so this user will not get result yeah so as you can see the user field is empty so let's go ahead and make the change and see what changes need to do so first we need to go to this particular script include and within this script include we have a method called get sis user this expanded so as you can see within this method we first try to correlate in the sis user uh table with the email and then with the username so given our use case we'll try to correlate it with the first name so I just copied the code just to save some time and instead of username I'll be using the first name field and the value that we're matching is this username that is the split of user principal name that is we are just removing the domain part and now that's it so with this change now we will the user will get resolved with the autobbox logic that is email and username but along with that we have added a custom logic to also check it with the first name so if there is any match with either of these any condition the user will get get resolved so I'll just save it and uh I'll create the same user again so I'll just replicate this Behavior just change the external ID to make it unique rest the US the principal name Remains the Same so now that this test should match with the first name the users should get resolved so let's give it a try so subscription record is created and as you can see for the user principal name test at example.com the user is resolved so this is how we can customize our uh out of box logic in the Sam as integration util to consider any other field or even if you want we can do a field combination to verify whether the user is present uh user can be resolved or not thank you