To add to the other forum I commented on....
This error can be caused by having the Application Client ID in early versions of 18.4 and 18.4, in the Company Email Settings window. This was fixed in later versions, where Workflow email works fine with modern authentication/Exchange emailing.
Otherwise, usually when we see the above in the Workflow logs, they’re caused by one or both of the following, which we’d want to verify whether or not are true in this Workflow environment or not:
1) The SQL Server service, that the Dynamics GP databases are held on, is being run by a local account or service account and not a domain account.
2) The Workflow users are setup on a domain that is different from the domain that Dynamics GP and/or SQL Server are installed onto. This is also true of users that are in the same Active Directory, but have different accounts, i.e. User 1@Contoso.com, User2@TestCo.ca, User3@TWO.local.
3) Less common would be if the DNS servers are valid internal domain controllers and there is a replication issue between them, if applicable.
As mentioned in this blog about Workflow and multi-domain environments, the ‘Unable to retrieve user….’ Message is actually expected, as it means the approver was not found on the initial domain that was looked at, so the code is now going to try and find the approver across other trusted domains.
Workflow 2.0 Performance in Multi-Domain Environments - Microsoft Dynamics GP Community
community.dynamics.com/.../workflow-2-0-performance-in-multi-domain-environments
Workflow doesn't work the best on multi-domain environments and/or using domain groups instead of users, for approvers on workflow steps, if you happen to have any type of these setups.
Thanks