User().Email display UPN value not Email

[SimonTocker]

Hi,

at this point in time Im working with a company that does not use the users Email as the UPN, this is a valid approach, its allowed,  whilst it causes problems with Invites to 365 sites, it is a valid scenario.

When In powerapps,  I I use the function User().Email,  then the users UPN is displayed,   this is not the users Email, but in testing because everyone users an email address in the UPN it is easily missed in testing.

In the picture below I hid the actual text being returned,   but the label below shows the format of the companies UPN,   it would look like   

    X99999@company.com   

The users SAMAccount is the prefix and the companys actual domain is the suffix,   it looks like an email address, but isnt and isnt tied to an exchange alias either.   So it cannot be used as an email,   

The User().Email   function and property needs to get the actual AzureAD email field.

[v-yuazh-msft · Accepted solution]

Hi @SimonTocker,

Does your email address and UPN are not the same?

The email address and UPN would be same by default, and I have made a test on my side with function User().Email, and the function would works fine to get the email address:

 

I afraid that your mail address and UPN is different, if you want to get the mail address and not the UPN, you could add connection Office365Users,and then take a try with function Office365Users.MyProfile().Mail :

  

Best regards,

Alice

[SimonTocker]

Hi. Yes they are different.

Thankyou for your advice Alice thats a good workaround, I will use that.

However My point is to inform the powerapps team of this. They should not be mistaking the two.

It is advised they are configured the same. But they do bot have to be.

Teams in Microsoft should be more aware and not just assume this and get the right attributes from the users ad attribs and not make assumptions.

I will admit that having a upn that is not your email is the dumbest move ever. If I could kick the idiot, who forced this on us, up and down the office car park I would, repeatedly, So would several others I know.

But please, if you are able, pass this BUG to the team.

Thanks
Simon

[DavesTechTips]

Hi everyone,

If you would like to see more information about this topic or the work around, please see below video.

Have a great day!

https://youtu.be/6FU1xGxJK5w

Dawid van Heerden
Follow on Twitter: @davestechtips
Subscribe to YouTube: https://www.youtube.com/davestechtips?sub_confirmation=1
**If you found this reply helpful, please mark this as the answer to close the topic and make it easier to find for other people with similar questions.

[DeeTronSEAM]

Two years later and @SimonTocker 's observation remains true. I.e. User().Email still displays the user's UPN and not their primary email address.  For most people the values are the same, but not all.

The PApps documentation should warn people of this, IMO.  I.e. page https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/functions/function-user 

So, I've entered an issue to request that warning be added to the docs.  

https://github.com/MicrosoftDocs/powerapps-docs/issues/1725 

If you're reading this and the docs still don't have the warning but issue #1725 is closed, feel free to make a new request to the doc team.

This cost me several hours, Microsoft.

[SimonTocker]

Good call,

Long term, I'd prefer Microsoft actually fix this, there is an email attribute in AD they can actually refer to.

What about it MS?   🙂

[admlaflammm]

**bleep** MS can you fix this??? This is a BUG!

How many man hours people are speding patching this 😞

[JimmyWork]

Please fix this MS

[Django]

Different primary email addresses from the original UPN is a common use case.

Especially since the Send From Email address that email receivers see, is the primary email address.

If people get married and want an updated primary email address, this should be possible without User().Email breaking down...

User().Email which is in fact Azure AD UPN --> I can imagine that backwards compatibility in changing this function now would be hard for Microsoft to do but a warning in Microsoft Docs is the least that can be done.
Cannot believe that @DeeTronSEAM GitHub issue is still openen...