We have had an issue with our form and workflow where the email address for a user does not match their username. This is not a data quality issue, there is a valid reason why the primary SMTP/email address is different from their email address.
I have a form with a data lookup control with an Azure Active Directory data source.
This only returns the email address of the user.
We use this to assign a task (form based) to the user.
The user receives an error that they cannot access the form.
So as an example the email is firstname.lastname@example.org
The username is email@example.com
The task is assigned to firstname.lastname@example.org, however the user assigned the particpant role is against their username of email@example.com. And when they log in to NWC they see no assigned tasks in the mytasks dashboard.
So the tasks actually need to be assigned to the username of the user not their email address when using Azure AD.
I can put in a workaround of 'get user detail' Azure AD action to query for the username and store that in a variable.
I'm hoping that upcoming improvements to return objects from the data lookup control with an Azure AD data source can also return the username as well as the email for use in assigning tasks.
(That we do not need to perform additional steps in the workflow)
@butlerj hoping that this can be added to the control development.
Hey @Gavin-Adams, did some testing this morning, and it seems that we were able to assign an authenticated task to a user just using the email from the Data Lookup:
Can you let me know if the above is the same way that you have things configured in your environment?
yes that is how we have the data lookup control configured.
For 99% of the users that worked fine.
Data user control return the email address of the user and used that to assign the task to that user.
The issue in this case is that when the authenticated user logs into NWC for the form task, it appears to be looking at the username of the user for the tasks that are assigned.
For this one user the email address that is in the 'Assignee' on the task is different from the username that user authenticates with.
Ahhh I got ya. Sorry I didn't pick-up on that in your initial post :?
I'll keep working to see if I can replicate that behavior so the team knows exactly what they would be looking at from a configuration stand point. Out of curiosity, is your NWC environment federated to the Azure AD instance, or just using standard auth?
Thanks for keeping on this one.
That's correct NWC is federated to Azure AD.
The clients Azure AD is synchronised with an on-premise Active Directory.
I just tried in a test office 365 environment to set a different primary email to a username and I could not do it. This test environment is not sync'd to an on-premise Active Directory, so it might be part of the fact that the user account originates from on-premise active directory.
(Office 365 user account being sync'd from on-premise AD is a very common scenario for most organisations though.)
I've taken a screenshot from my client and overlayed the picture with some sample values so you can see what the user account properties look like in Office 365.