KhalilK.30860 (Customer) asked a question.
Okta group memberhip add/remove events are not fired when membership change was imported through Active Directory app integration
I have implemented Azure Active Directory integration and we are also using Okta Event Hooks. The issue we are facing is that when a user's group membership is added or removed in Active Directory and the import process is performed, although the membership change is reflected in Okta directory but we do not receive the 'group.user_membership.add' and 'group.user_membership.remove' events. Other events like User create, deactivate, group create etc are received. I have tried different settings but for no help. Please note that group membership related events are registered and they are also called when we directly change the membership from Okta directory.
@KhalilK.30860 (Customer)
There are only a subset of the total events that can be event-hook-eligible in which you can see the whole list of events (and filter them to eligible) here:
https://developer.okta.com/docs/reference/api/event-types/#catalog
When the import occurs are you seeing a specific event where the user's group membership is changed? If you filter the System log to a specific user ID then review the events that occurred during the import (Event.EventType) you should be able to identify first "IF" an event is shown for the group change and if there is an event the specific event type. You can then check to see if that event is eligible or not.
As the event hooks are not really a part of the Workflows product (Workflows can be configured to be a target for the Event Hook payload to invoke a Workflows execution either by using an Okta - Event card or as an API Endpoint) there isn't going to be any change configurable on the Workflows side that will modify your described behavior.
However, if you can identify the specific event you have two paths:
1) You can create an https://ideas.okta.com with the intent to expand the eligible events
2) You could configure Workflows to search the system log looking for specific non-eligible events. This could be done on a schedule (as short as 5 minutes). If results are found you could then build out logic to do something with those results.