How to skip or gracefully handle getObjectSQL execution when the target user has been hard-deleted?

1. What are you trying to do or solve?

We are using the SailPoint JDBC connector for several target applications and trying to understand how to handle a case where the target user has already been hard-deleted from the system before SailPoint executes the connector’s getObject SQL.
The issue is specifically during post-provisioning / account verification:
SailPoint executes getObjectSQL with the identity value in the $(identity) / bound parameter position
The user record no longer exists in the target system because it was permanently deleted
We want to know whether the connector can skip getObject execution for that case, or whether it always executes and requires the query itself to handle the missing row gracefully
Examples of the errors we are seeing:
ORA-01722: invalid number
ObjectNotFoundException: Object not found: select … and ut.user_id = ?

We want to understand the supported behavior when the target account is already deleted externally, especially whether this should be treated as a normal “not found” condition rather than a connector failure.

2. What have you already tried or configured?

We have reviewed the JDBC application configuration and are using getObjectSQL against Oracle-backed target systems.

Current behavior:
The query is built in the connector with the identity value passed as a bound parameter
The SQL compares the identity value against a numeric identifier column in the target database
When the user row has been hard-deleted, the query may return zero rows or fail due to the implicit type comparison
We have also validated that:
the target user is no longer present
the user identity value is still passed into the query
the query fails during getObject execution after provisioning
We are trying to determine:
whether the JDBC connector supports skipping getObject execution when the target user is already deleted
whether any connector-level or code-level option exists to handle “not found” more gracefully

3. Environment Details

  • Product & Version: (e.g., Identity Security Cloud, IdentityIQ 8.4)IdentityIQ 8.5p1
  • Source / Connector: (e.g., Active Directory, Workday, ServiceNow) JDBC Connector

We also noticed the exception for getObjectSQL when we were moving to 8.4P4, The error was always there, it is now better handled as exception as per SailPoint, thats why we see the error in connector provisionings. Unlike yours we needed the query to be run during account creation and gave the same exception so we ended up not using getObjectSQL parameter at all and everything worked as expected.

Thanks,
Manjesh

thankyou manjesh for your response. We will check whether we can implement the same approach.