Microsoft Security | Microsoft Entra | Microsoft Entra ID
A cloud-based identity and access management service for securing user authentication and resource access
Azure Enterprise Application: User Provisioning Automation for Salesforce: Is Microsoft updating this feature to not use the SOAP login() operation?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(227.2, 63%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETD%3C/text%3E%3C/svg%3E)
Turkel, David (TKE)
35
Reputation points
The Salesforce SOAP-based login() service is going to be retired as part of the Summer '27 release (https://help.salesforce.com/s/articleView?id=005132110&type=1). It appears the Azure User provisioning function is using this login and get its session ID for operating against Salesforce, and there is no alternative Authentication Type available to select in the credentials configuration (like OAuth 2.0 seen in other enterprise application types)
Obviously this will be problem if not addressed on the Azure Enterprise App side.
What is the roadmap (when is this going to be added/modified) for addressing this in the Azure Enterprise App User Provisioning functionality, so we have continuity of the functionality?
Microsoft Security | Microsoft Entra | Microsoft Entra ID
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(233.6, 85%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EVS%3C/text%3E%3C/svg%3E)
VEMULA SRISAI 14,080 Reputation points Microsoft External Staff Moderator2026-01-14T21:45:54.83+00:00 Hello Turkel, David (TKE),
It seems like you're raising a valid concern about the Salesforce SOAP-based login() service being retired in the Summer '27 release and its impact on the Azure User Provisioning functionality. Currently, Azure relies on the SOAP login to obtain session IDs for interacting with Salesforce, and the lack of an alternative authentication method like OAuth 2.0 is certainly troubling.
At this time, Microsoft hasn't specified a public roadmap regarding modifications to the Azure Enterprise Application User Provisioning feature related to the deprecation of the Salesforce SOAP login method. However, I recommend keeping an eye on any updates via the Microsoft Entra documentation and official announcements.
In the meantime, there are a few options and best practices you might consider:
Leverage SCIM: If you haven't already, look into integrating using SCIM (System for Cross-Domain Identity Management) which is supported for user provisioning with Microsoft Entra ID. This might provide a more future-proof approach to provisioning users.
On-Demand Provisioning: You can use Microsoft Entra's on-demand provisioning capabilities to initiate user provisioning when needed, which could serve as a temporary workaround while waiting for updates or changes.
Monitor and Troubleshoot: For current provisioning issues, utilize the User Provisioning Troubleshooting Guide. This can help diagnose and resolve any existing user provisioning problems.
Request for Updates: Consider submitting feedback to Microsoft through Azure support channels or forums to express the urgency of this issue with Salesforce integrations.
Relevant Links:
- User provisioning documentation
- SCIM provisioning configuration
- Provisioning logs
- Troubleshooting user provisioning issues
If you have any additional questions or need further clarification, feel free to ask!
-
Turkel, David (TKE) 35 Reputation points
2026-01-14T22:46:03.4566667+00:00 Yes, reviewing and implementing SCIM may be an option, however the existing functionality is fully configured and working operationally to manage 1000's of users. Manually management using the "Provision on demand" feature is not reasonable/tenable. The definition of the Enterprise Application as being Salesforce limits the options immediately, and therefore require re-establishment of new Enterprise Applications and coordination that seem avoidable.
Since other "packaged" enterprise application types have OAuth-type flows/configuration supported, this seems like a relatively simple addition to the functionality provided, all to get the same token used for all subsequent operations.
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(281.6, 27%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDG%3C/text%3E%3C/svg%3E)
Declan Galli 0 Reputation points2026-11-10T04:56:07.74+00:00 Adding to this, and asking the Entra provisioning team to take another look now that the deadlines are firm.
We use the gallery "Salesforce" app with automatic provisioning. It works today, but every cycle shows up in Salesforce Login History as a SOAP Partner API v40 login(). Salesforce has emailed us an "ACTION REQUIRED" notice every month since September after detecting these calls. The notices set firm dates: "Use Any API Auth" is required from Dec 1, 2026, security tokens are enforced for broad IP ranges from Jan 31, 2027, and full retirement is in Summer '27. They also tell admins to contact the third-party vendor for an OAuth version. For this connector, that vendor is Microsoft.
There's nothing we can change on our side. The connector's template (Graph: servicePrincipals/{id}/synchronization/templates) shows SupportedAuthenticationTypes = ["Basic"] and IsOAuthEnabled = false. The non-gallery SCIM route doesn't work either. Salesforce requires a ProfileId entitlement, and Microsoft's SCIM documentation states "The entitlements attribute isn't supported" (see 5834251).
The January reply said no roadmap had been specified. Could the team reassess and share: (1) Is OAuth 2.0 (External Client App, client credentials or JWT bearer) planned for the gallery connector before Summer '27, and when? (2) Will existing apps migrate in place, keeping mappings and scoping? (3) If not, what is the supported path?
Related threads:
We're opening cases with both Microsoft and Salesforce.
Sign in to comment
Sign in to answer