question

MaxNowak-7132 avatar image
0 Votes"
MaxNowak-7132 asked JamesTran-MSFT commented

Azure AD to ServiceNow provisioning: re-syncing groups deleted in ServiceNow

Hi,

We're using user / group provisioning from Azure AD to ServiceNow and have run into a problem.

When creating a group in Azure, it gets synced to ServiceNow, as expected - but when this group is deleted in ServiceNow, it is NOT synced back to ServiceNow automatically, which was pretty surprising. It seems like Azure is not synchronizing every 40 minutes, like it is stated, but it is checking every 40 minutes if changes were made on its side (for example, removing someone from a group), and only then synchronizes the current state to ServiceNow. We tested this by deleting a group in ServiceNow and waiting for Azure to synchronize it back (since it was still present in AD), but nothing happened. Once we added a new member to the group, the group got synced back to ServiceNow.

Is there any way to change this behavior, so that the state present in Azure AD will always be synced to ServiceNow, regardless of if the objects have been deleted in ServiceNow? We really want Azure to be the source of truth for groups and users, but currently, that's just not possible.

Thanks,
Max

azure-ad-user-provisioning
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

JamesTran-MSFT avatar image
0 Votes"
JamesTran-MSFT answered JamesTran-MSFT commented

@MaxNowak-7132
Thank you for your post and I apologize for the delayed response!

Based off your description, when you delete a group in ServiceNow, it isn't getting sync'd back to AzureAD. However, if you add a new member to the group (I'm assuming within AzureAD), the group gets sync'd back to ServiceNow.

From our "How provisioning works" documentation, it seems like the provisioning service is working as expected since it will query the source system - Provisioning cycles: Initial and incremental
95366-image.png

I also found a known issue which might be related to this issue as well - Changes not moving from target app to Azure AD: This is because the app provisioning service isn't aware of changes made in external apps. So, no action is taken to roll back. The app provisioning service relies on changes made in Azure AD.


If you have any other questions, please let me know. Otherwise, I'd recommend leveraging our User Voice forum to provide feedback or creating a feature request so our engineering team can take a look into implementing this.


Thank you for your time and patience throughout this issue.


Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.


image.png (130.2 KiB)
· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

@MaxNowak-7132
I just wanted to check in and see if you had any other questions?

Thank you for your time and patience throughout this issue.

0 Votes 0 ·

@JamesTran-MSFT hit the nail on the head - AAD Provisioning does not have a way to query target directories for changes. It relies solely on changes in AAD. If changes have been made in the target app (ServiceNow or anything else), to bring things back to a correct state you should restart provisioning so that all in-scope objects in AAD are evaluated, rather than only objects that have had recent changes in AAD. By restarting, you'll force the service to evaluate the group again and when it sees that the group no longer exists in ServiceNow, it will recreate it.

1 Vote 1 ·

@MaxNowak-7132
I just wanted to check in and see if you had any other questions or if you were able to resolve this issue?

Thank you for your time and patience throughout this issue.


Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.

0 Votes 0 ·