Hi,
My organisation as recently changed it's email domain name and this seems to have affected one of the PowerApps that our HR department use.
Part of the security only the Line manager can submit a request for a changes to one of the staff members contract. (Hours, pay, promotion, etc.) Part of the logic uses the Office365User connector and if the name and email match that of the managers name, email then they can submit a form. If it doesn't an error message appears stating that you cannot submit the request.
Checked our SAP and Azure AD and the emails for all employees are displaying the new domain name
Since the change this error message is appearing for when the manager is the manager for the selected staff member??
The strange think is it's not happening for everyone, but can't find a discrepancy between them?
I've removed the Office365User and Office365Outlook connector and re-connected them hoping this will push the changes through.
Solved! Go to Solution.
Hi @ClarkyPA365 ,
If the issue is in the casing, the below formula should cover it:
!(
IsBlank(EmployeeValue.Selected) ||
(Lower(DataCardValue8.Text) = Lower(_UserEmail) || Lower(DataCardValue98.Text) = Lower(_UserEmail)) ||
isUserSeniorAdvisor
)
As you may notice, I also removed the If function because the conditions in there will already return a boolean with which the Visible property can work.
Hi @ClarkyPA365 ,
Since this is working for some people and not for others, I advise you to look for some examples because this is more than likely a data quality issue. Depending on the issue you may be able to provide a workaround, for instance:
Some upper case characters were used: Nest all references to Email addresses in a Lower() function.
Hi @BCBuizer
Thank you for this as I have checked in our Azure and I did spot that the User Principal Name does differ.
There are upper case characters in the format for those that can't and all lower case for those that can.
I'm asking if one of those that have upper case can be amended to lower case to test the theory.
If this is the cause where would I put the workaround and how?
I've asked they can amended it in Azure??
Hi @ClarkyPA365 ,
If the issue is in the casing, the below formula should cover it:
!(
IsBlank(EmployeeValue.Selected) ||
(Lower(DataCardValue8.Text) = Lower(_UserEmail) || Lower(DataCardValue98.Text) = Lower(_UserEmail)) ||
isUserSeniorAdvisor
)
As you may notice, I also removed the If function because the conditions in there will already return a boolean with which the Visible property can work.
Hi @BCBuizer ,
Thank you.
Just a couple of questions.
Do i need to replace If with ! ?
Is the first bracket required || (Lower ?
Hi @ClarkyPA365 ,
I removed the If because it is not necessary. However, just removing it would have reverse the outcome of the formulate, so that's why I used the !.
The first bracket to which you are referring is included in the original formula you posted, so I copied it from there. I guess it was included to combine the two middle conditions.
Hi @BCBuizer ,
I've applied this formula to a test app and it seems to have worked for one user, but waiting on reply from other users, but things are looking good.
As I'm not sure how many parts of the app and potential other app, I need to apply this workaround, I'm hoping that changing the an element in Azure AD will rectify it.
As mentioned I'm using the Office365User connector.
Doe this use the User Principal Name (UPN) as it's check to the users email address? I've identified that the users who have the same format of UPN and email address are fine and can use the app those that don't have the same format can't and the workaround you provided seems to rectify this. But if one change was made in Azure would this rectify it as well??
Hope that makes sense ??
Some of the apps use Flow and have the office 365 user connector as a step and noticed it uses the UPN
So would making the UPN and email the same format in Azure AD, in theory would resolve this issue??
Hi @ClarkyPA365 ,
Short answer? yes. However, if this happened once, it can happen twice, hence the recommendation to add this workaround to add resilience to your apps.
Hi @BCBuizer ,
I was hoping you would say Yes.
I'm think of getting this done as a quick fix so
1) Users can start using the apps
2) Get the HR dept of my back whilst I go through the apps applying the workaround
3) give me time to apply the workarond
Hi@BCBuizer,
Sorry just one other question regarding this.
If a formula contains, _userEmail is it prudent to add Lower at the beginning, through out the app???
User | Count |
---|---|
252 | |
107 | |
88 | |
51 | |
44 |