Azure AD SCIM provisioning - Queries on gallery app, multiple simultaneous updates, provisioning jobs

Question

Hi,
We have few queries related to Azure AD SCIM provisioning.

1. Without non-gallery SCIM application, what are the list of features which are not available during SCIM integration in comparison to Azure AD gallery application.
   Below is the list which we are able to get from multiple documents. Are there any other missing features?
   - Unavailability of OAuth setup on the non-gallery applications
   - Schema discovery isn't currently supported on custom non-gallery SCIM application
2. When there are multiple updates in Azure user directory with respect to same user or group which could be part of same provisioning cycle, will there be parallel calls for these updates or will these changes be sequentially updated. For instance user getting updated, added/removed from multiple groups, is there any possibility of overlapping updates.
3. While testing Provisioning apis used to get and start the scim applications, we are getting the response using only the beta APIs. (https://learn.microsoft.com/en-us/graph/api/synchronization-synchronizationjob-post?view=graph-rest-beta&tabs=http). Please suggest if there is any timeline to get the production ready apis.

Answer 1

Hi Ruchi,

• For #1, in addition to the points you have identified, the most common ones I'd call out are the lack of support for custom complex and/or multi-valued attributes and the lack of support for rate limiting the number of requests per second that the AAD SCIM client sends to the SCIM server. One other less commonly used feature that is not available on generic SCIM app is the ability to do what we call a batch patch of group membership updates - that is, one HTTP PATCH request containing add/remove for more than one member at a time. There may be others, but the ones I have just mentioned are the most common and are the only ones that come to mind while writing this answer.
• For #2, changes to the same user object are typically all made in a single PATCH call. The exception to this is usually the manager attribute, which is sent later due to the need for some additional backend validation on our side as the value is a reference to another user object. For groups, membership changes will always be processed one at a time - one PATCH request per membership add/remove. Referencing the answer for #1 above, gallery integrations can be built to do more than one change in a single PATCH.
• For #3, we're working on bringing the APIs out of beta but I don't believe there is a publicly available timeline.