We’re evaluating authentication options for our travel management module in D365 10.0.42. Currently using local authentication, but considering SSO integration with our corporate identity provider. Looking for real-world experiences comparing these approaches.
Main considerations: SSO compliance with our security policies, mobile authentication for traveling employees, and overall user experience. Our travel approvers need mobile access, and we have about 200 users who submit expense reports and travel requests regularly. What have others experienced with SSO vs local auth in travel management scenarios? Any gotchas with mobile authentication we should know about?
Minimal setup; already operational in your environment
Travel approver mobile access
Power Apps mobile and browser-based approval flows handle SSO tokens well
Session re-authentication friction is common complaint from mobile approvers
Key Gotchas — SSO in Travel Scenarios
Claim mapping drift is the most common silent failure. If your IdP sends UPN but D365 expects email as the matching attribute, authentication succeeds but user resolution fails — resulting in broken expense delegation and approval routing. Validate your Azure AD (or third-party IdP) attribute mapping against D365 user records before cutover.
Conditional access conflicts trip up mobile approvers. If your corporate policy enforces compliant-device requirements, traveling employees on personal devices or hotel networks may get blocked during CA policy evaluation. Define a travel-specific conditional access policy or named location exclusion.
Token lifetime in offline modes — D365 Finance mobile scenarios rely on cached tokens. Default token lifetimes may expire mid-trip. Review Microsoft Entra ID token lifetime policies and configure appropriately for your travel duration norms (verify in your version for supported token configuration options).
Local Auth Retention Case
At 200 users, local auth isn’t inherently unmanageable. If your IdP infrastructure is immature, you’re running a hybrid on-premises topology, or you have significant offline field requirements, the added complexity of SSO federation may not pay back quickly.
Recommendation Frame
SSO becomes clearly advantageous when: your IdP already enforces MFA, your security team requires unified audit logs, and mobile approver friction is a stated pain point. Local auth remains defensible when operational simplicity and offline resilience outweigh centralized identity governance.
Ultimately depends on context / your requirements — specifically your IdP maturity, conditional access policy flexibility, and how your travel approvers’ device compliance is managed.
This draft is based on general Microsoft Dynamics 365 knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
We made this transition last year. SSO dramatically improved user experience - single sign-on means travelers don’t juggle multiple passwords. Mobile authentication was the game-changer. With SSO, users authenticate once on their mobile device and stay logged in. With local auth, they had to re-enter credentials frequently, especially frustrating when submitting expense reports from airports or hotels.
From SSO compliance perspective, it’s a clear win. Centralized identity management means consistent password policies, MFA enforcement, and immediate access revocation when employees leave. Local authentication creates compliance headaches - separate password resets, no MFA integration, and orphaned accounts. For travel management specifically, you can enforce conditional access policies like requiring MFA for expense approvals over certain amounts. Can’t do that easily with local auth.
Mobile authentication is where SSO really shines, but be aware of offline scenarios. Travelers in areas with poor connectivity might struggle if your SSO requires constant validation. We implemented token caching for the D365 mobile app so users can work offline for short periods. Also consider your SSO provider’s mobile SDK - some are better than others. Azure AD works great with D365 mobile, but we had issues with other providers requiring custom integration work.
One downside to SSO - you’re now dependent on your identity provider’s uptime. We had a corporate Azure AD outage that blocked all travel expense submissions for 4 hours. With local auth, D365 availability is independent. That said, the benefits still outweigh this risk. Just make sure you have SLAs with your SSO provider and communicate dependencies to your users.
The user experience advantage is significant but don’t underestimate the compliance benefits. We’re in financial services with strict audit requirements. SSO integration gave us:
SSO Compliance Benefits:
Centralized audit trail across all systems including D365 travel management
Automated compliance with corporate password policies (complexity, rotation, history)
Real-time access revocation when employees terminate or change roles
Integration with our SIEM for security monitoring and anomaly detection
Single source of truth for user identity and access rights
With local authentication, we had to manually audit D365 accounts quarterly, track separate password policies, and coordinate access removal across multiple systems. SSO eliminated that overhead.
Mobile Authentication Considerations:
For traveling employees, mobile authentication with SSO provides several advantages:
Biometric authentication (fingerprint, face ID) leveraging SSO provider’s capabilities
Seamless experience across D365 mobile app and web portal
For 200 users submitting regular expense reports, that time savings adds up. We measured 30-40 seconds saved per login. Users authenticate 3-4 times daily on average, so roughly 2 minutes per user per day saved.
Migration Approach:
We ran parallel authentication for 30 days:
Week 1-2: SSO available as option, local auth default
Week 3: SSO default, local auth available as fallback
Week 4: SSO only, local auth for emergency admin access only
This gave users time to adapt and let us identify issues before full cutover. Key lesson: communicate clearly about password manager implications - some users had D365 credentials saved and were confused when SSO bypassed them.
Technical Gotchas:
Token lifetime configuration - set appropriately for mobile use (we use 8-hour access tokens, 30-day refresh tokens)
Conditional access policies - don’t make them so strict that legitimate mobile use is blocked
Guest user access - if external auditors or consultants need travel management access, ensure your SSO supports B2B scenarios
API integrations - if you have automated travel booking integrations, they’ll need service principal authentication, not user SSO
Overall recommendation: SSO is the right choice for travel management, especially with mobile users. The compliance, security, and user experience benefits far outweigh the dependency on your identity provider. Just plan the migration carefully and ensure your SSO provider’s mobile capabilities meet your needs.