Native Change Detection

Thank you for joining our community @PabiMalla!

The best way to manage accounts and entitlements on a source is to let IDN do it through connectors. SailPoint’s official connectors should be able to provision accounts and entitlements without manual intervention, but you may have custom connectors for your SaaS apps or on-prem apps that don’t have the same level of functionality. If a custom connector for your source doesn’t support account provisioning, then next I would look into updating the connector code to support that functionality so source owners don’t need to manually provision accounts. If all of your sources in IDN can provision accounts, then there should be no need for source owners to manually create accounts directly in the source. To enforce IDN as the sole mechanism for managing source accounts, I would consider training application owners to use IDN for account management on their applications, and then restrict admin access on the sources to only those application owners that are trained on the proper process.

That being said, change detection in IDN is supported through our event triggers, which provide a real-time mechanism for detecting when changes are made within IDN. ETS can detect changes, such as identity created, and alert you in real-time. ETS is purely used for detection and has no mechanism for action, such as reverting a change. There are various ways you can consume ETS, such as custom applications, iPaaS platforms like Zapier and Workato, or our new Workflows tool within IDN. Each of these methods will allow you perform actions based on an event, but they will require some level of coding experience to implement. In theory, you could use one of the approaches I mentioned to detect when an change has occurred, figure out if the change came from IDN or from the source application, and then execute some logic to revert the change on the source application.