Hi Phil,
The main issue is that the OIDC authentication flow does not have the Mendix user/session yet, so I would not try to retrieve the GUID through a microflow before authentication.
The better approach is to let the Deep Link carry the GUID through the OIDC login, and only execute the microflow after OIDC has created the Mendix session.
For Mendix 9 using the Deep Link + OIDC SSO modules, configure the Deep Link module's LoginLocation constant as:
/oauth/v2/login?cont=
The important part is the cont= at the end. Mendix appends the original Deep Link URL to this parameter, so the GUID remains available after authentication.
For example:
https://myapp.com/link/viewrecord/12345678
Flow:
Email link ↓ /link/viewrecord/12345678 ↓ Not authenticated ↓ /oauth/v2/login?cont=/link/viewrecord/12345678 ↓ Microsoft Entra ID / OIDC login ↓ Mendix session created ↓ Original Deep Link restored ↓ DeepLink handler microflow ↓ Retrieve record using GUID ↓ Open required page
The handler microflow can then use the GUID because it is executing after authentication, when the Mendix user/session is available.
Also, if the application is on Mendix 10.6+, I would not build a new solution around the deprecated Deep Link module. Mendix replaced it with Page URLs and Microflow URLs, and the current OIDC module supports these URLs, including query-string parameters. From Studio Pro 10.9 onward, primitive microflow parameters can also be configured as query-string parameters.
So for a newer application, you could have something like:
https://myapp.com/mf/ViewRecord?RecordGUID=12345678
and let OIDC handle the authentication/continuation before the microflow executes.
One thing I would specifically check in the current implementation: if the login succeeds but the user still lands on the default home page, verify the LoginLocation/continuation configuration first. A missing cont= is a common reason the original Deep Link gets lost.