LDAP sync issue for record deletion in LDAP

[venkata satish]

Hi All,

                 We have an LDAP integration that synchronizes custom data from LDAP to a custom table in ServiceNow. Currently, the integration successfully handles record inserts and updates. However, we are facing an issue when records are deleted directly from LDAP. ServiceNow does not receive any notification or information about these deletions, resulting in obsolete records remaining active in the custom table.

               Could you please suggest the best solution to identify records that have been deleted from LDAP and automatically update the corresponding records in ServiceNow by setting them to Inactive?

We would appreciate your recommendations and best practices for handling this scenario efficiently

                Thank you for the help.

Regards,

Venkata 

[Mehta]

 , 

By Default the LDAP deleted records does not have any trigger to  notify Servicenow. You might need to ask the LDAP team to configure a trigger to be listen by servicenow before the record gets deleted and then design a script to deactivate or delete the record from servicenow. 

One of the solution we have implemented, When the user gets deactivated we sync that in ServiceNow user table. We keep the record as deactivate for auditing purpose. we also have a schedule job runs and check if a user last updated or last login is more than 180 days then we automatically deactivates it in ServiceNow. As per Best Practice you should not delete user record as it might have impact on another data and might be an issue in auditing. Best is to develop a logic based on some criteria to deactivate an user, 

[VJ_Srivastava]

Hello @venkata satish ,

From an architectural perspective, the issue you are facing highlights the inherent limitations of standard scheduled pull integrations compared to modern event-driven architectures.

When ServiceNow executes an LDAP import, it performs a stateless transaction. The platform does not inherently track what was removed between batch runs. While running a full sync coupled with a timestamp comparison is the traditional workaround, it creates significant technical debt. As your data volume scales, forcing the database to perform a full table sweep every night just to catch a handful of deletions introduces severe performance overhead.

For enterprise-grade synchronization, I strongly advise shifting away from direct LDAP pulls for custom data if deletions are frequent and time-sensitive. Instead, consider utilizing a middleware orchestration tool or Identity Governance Administration (IGA) platform that can push webhook events directly to ServiceNow. Moving to an event-driven architecture ensures that a deletion in the source system immediately triggers a corresponding REST API call to deactivate the record, keeping your tables accurate in real-time without the batch-processing overhead.

[Tanushri]

Hi @venkata satish ,

Thank you for raising this! From a business operations and data governance standpoint, these "ghost records" are a massive liability.

When obsolete data is left active in your custom tables, it does not just sit harmlessly—it actively degrades trust in the platform's integrity. If this custom data is utilized to drive approvals, workflow routing, or asset assignments, those orphaned records will eventually cause misrouted tickets, inaccurate operational reporting, and potentially serious compliance violations during audits.

Getting this resolved is critical to maintaining a clean data model. Ensuring that your ServiceNow instance acts as a perfectly synchronized reflection of your source of truth immediately improves process reliability and eliminates the manual, reactive cleanup work your operational teams are likely forced to perform right now!