Problem: "The redirect URI specified in the request does not match the redirect URIs configured for the application. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal."
Solution: This error usually happens when one of the following three things don't match with the others:
- The HomeURL variable in Visionflow (you can see this variable from General -> Settings -> Other configurations -> Security).
- The redirect URI specified in the request. This is the URL you use to log in to your VisionFlow instance.
- The redirect URI configured in Azure.
When clicking the "Authorize using your own account" button in the email ticket system mail settings page, you need to make sure that you are logged in to VisionFlow via the same URL as is in your HomeURL variable. If you are, then the request sent by your web browser to Azure will have the correct redirect URI. And that same URL needs to be configured as a redirect URI in Azure.
Note: Installed on-premise customers can manually set their HomeURL variable via General -> Settings -> General -> Server Properties.
Problem: "BAD User is authenticated but not connected"
Solution: Sometimes you get an error like "BAD User is authenticated but not connected" when clicking "test connection" or when activating an email ticket system.
This normally happens because the Microsoft account that you have used when authorizing/authenticating the email ticket system by clicking on the "Authorize using your own account" button does not have permission to access the mailbox or folder that you have specified in the username field on the email settings page in the email ticket system.
To solve this you need to make sure that the Microsoft account used for the initial OAuth authorization to Microsoft also has access to the mailbox specified in the username field on the email settings page in the email ticket system.
A common mistake when filling in the "API Secret" field in VisionFlow is to use the API secret Id instead of the actual API secret value when copying it from Azure/Office365. As both these values look similar it is easy to pick the wrong one. The API secret value usually contains at least one ~ character, which the API secret Id does not seem to do.