We recently implemented automated user provisioning from Azure AD to D365 Finance & Operations resource management module to eliminate manual onboarding delays. Our HR department was experiencing 3-5 day delays creating user accounts and assigning proper security roles, which impacted new employee productivity.
The implementation focused on three core areas: establishing seamless Azure AD integration with D365, configuring automatic user creation workflows triggered by HR system events, and implementing role-based provisioning logic that maps organizational positions to appropriate security roles.
Our solution leverages Azure AD’s SCIM provisioning protocol combined with D365’s security framework. When HR creates a new employee record in our HRIS system, it triggers an Azure AD user creation event that automatically provisions the corresponding D365 user account with pre-configured security roles based on department and job function.
// Provisioning flow - Key steps:
1. HR system creates employee → triggers Azure AD webhook
2. Azure AD provisioning service creates D365 user via SCIM endpoint
3. Custom logic maps job_title + department → security role assignments
4. D365 SystemUser entity updated with roles and default settings
5. Welcome email sent with login credentials and role information
The implementation reduced our average onboarding time from 4 days to under 2 hours. We’re now provisioning 15-20 users monthly with zero manual intervention. Happy to share configuration details and lessons learned.
Great question! We built a custom mapping table in D365 that connects Azure AD group memberships to security roles. The table has columns for AAD_GroupID, D365_SecurityRole, Department, and JobFunction. When the provisioning service creates a user, it queries this mapping table based on the user’s department and job title attributes from Azure AD.
For 35 roles, I’d recommend starting with your most common roles (probably 10-15 cover 80% of users) and implement those first. We used a phased approach - started with finance and operations teams, validated the mappings worked correctly, then expanded to other departments. The mapping logic runs as a custom plugin that executes during user creation.
One critical lesson: keep the mapping table well-documented and give your HR/IT team a simple interface to maintain it. We built a basic form in D365 for this purpose.
Impressive implementation! Did you encounter any challenges with the SCIM protocol integration? We tried setting this up last year but ran into token expiration issues and rate limiting from Azure AD. How did you handle authentication and ensure reliable provisioning during high-volume periods like seasonal hiring?
Role changes are handled automatically through the same Azure AD sync mechanism. When HR updates an employee’s job title or department in our HRIS, it triggers an attribute update in Azure AD, which then syncs to D365. Our custom plugin detects the attribute change and re-evaluates the role mapping.
However, we implemented a safety mechanism - instead of immediately revoking old roles, the system adds new roles first and flags the old roles for review by a security admin. This prevents access disruption if someone needs temporary dual-role access during transition periods. After 48 hours, a batch job automatically removes the old roles unless an admin has marked them for retention.
For promotions to management positions with elevated privileges, we added an approval workflow that requires security team sign-off before high-privilege roles are assigned. This balances automation with proper security governance.
This is exactly what we need! We’re still doing manual user creation and it’s a nightmare with our growing headcount. Quick question - how did you handle the Azure AD to D365 security role mapping? Did you create a custom mapping table or use some built-in functionality? We have about 35 different security roles across departments.
Yes, we definitely hit some bumps with SCIM! Token management was our biggest challenge initially. We implemented a token refresh mechanism that renews the Azure AD service principal token 10 minutes before expiration. The refresh logic runs as a scheduled batch job in D365.
For rate limiting, we added retry logic with exponential backoff - if we hit the Azure AD rate limit (which happened during our summer intern onboarding wave of 45 users), the system waits and retries rather than failing. We also implemented a provisioning queue that batches requests during high-volume periods instead of firing them all simultaneously. During our peak month, we provisioned 23 users in one day without issues.
Monitoring is crucial - we set up Application Insights to track provisioning success rates, token refresh events, and any SCIM errors. This helped us catch and fix issues before they impacted users.
This sounds fantastic. We’re evaluating this for our D365 10.0.42 upgrade. How do you handle role changes when someone gets promoted or transfers departments? Does the system automatically update their security roles or is that still a manual process?