Title: SQL Loader Connector — Provisioning Gap: Only 261 out of 568 accounts written to CSV when using Birthright (BR) Role Assignment

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Environment

  • SailPoint Identity Security Cloud (ISC)
  • Connector: SQL Loader (JDBC / HXTT CSV Driver)
  • Rule Type: JDBCProvision Rule
  • Source: CSV file hosted on Azure Blob SFTP endpoint
  • ISC Version: Current SaaS

Background

We are using the SQL Loader connector to provision identity data into a CSV file (vcdiscprd.csv) hosted on an Azure Blob SFTP endpoint. The provisioning is triggered via a dummy entitlement approach — a Provisioning attribute with a static value is assigned through an Access Profile, which in turn triggers the JDBC Provision Rule to write a row into the CSV.

The connector is working correctly in the following scenario:

  • When a user manually requests access via the Request Center → provisioning fires → row is written to CSV :white_check_mark:

Issue

We assigned a Birthright (BR) Role containing the Access Profile to 568 identities. All 568 identities:

  • Have the role assigned :white_check_mark:
  • Show the Access Profile and entitlement on their Access tab :white_check_mark:
  • Show a VW-Export-PROD account under their Accounts tab :white_check_mark:
  • Show COMMITTED status in Provisioning Activity :white_check_mark:

However, only 261 rows were written to the CSV file. The remaining 307 identities have an account in ISC but no corresponding row in the CSV.

Key Observations

  1. The CSV file started completely empty — all 261 rows were created by our JDBC Provision Rule, confirmed by reviewing the file.
  2. All 568 provisioning activities show as COMMITTED — no failures or errors visible in ISC.
  3. When tested via Request Center (manual access request) — provisioning works perfectly and the row is written to CSV every time.
  4. The 307 missing identities are pre-existing identities in ISC with valid identificationNumber (emploeeNumber) values — null employee number is not the issue.
  5. Our investigation suggests that the 307 identities already had a correlated account on the VW-Export-PROD source in ISC from a previous aggregation. When the BR role was assigned, ISC did not fire a Create provisioning request for these identities because it considered them as already having an account on the source.
  6. The 261 identities who got provisioned correctly did not have a pre-existing account on the source — so ISC fired a Create request for them.

Root Cause Hypothesis

When ISC detects that an identity already has a correlated account on a source, it skips the Create provisioning operation even if the actual CSV row does not exist. This creates a data inconsistency — ISC believes the account exists (because it was previously aggregated) but the physical CSV file has no corresponding row.

This behavior is correct from ISC’s perspective (no duplicate accounts) but problematic when the source CSV was empty/reset and the physical data no longer matches ISC’s account state.

JDBC Provision Rule

Our rule handles Create, Modify, Delete, Disable, Enable, Lock and Unlock operations. The Create branch inserts a new row into the CSV with the required attributes. The rule is working correctly as confirmed by manual request center testing.

Questions for the Community

  1. Is our root cause analysis correct — does ISC skip Create provisioning for identities who already have a correlated account on the source, even if the physical CSV row does not exist?
  2. Is there a supported way to force re-provisioning (Create) for identities who already have a correlated account — without having to delete and recreate their accounts in ISC?
  3. Would triggering Attribute Sync for the 307 missing identities send a Modify request to the JDBC rule? If yes, could the Modify branch be used to INSERT a new row if no existing row is found (upsert logic)?
  4. Is there a better architectural approach for using SQL Loader as a provisioning target where the source CSV may be periodically reset or emptied?
  5. Has anyone else faced a similar gap between ISC account state and physical CSV file state when using SQL Loader?

What We Have Already Tried

  • Fixed CSV separator (_CSV_Separator=,) — no trailing spaces :white_check_mark:
  • Fixed JDBC Provision Rule — correct AccountRequest.Operation enum usage :white_check_mark:
  • Fixed SFTP password URL encoding (%2F for /) :white_check_mark:
  • Confirmed all provisioning activities show COMMITTED :white_check_mark:
  • Confirmed manual Request Center provisioning works correctly :white_check_mark:

Any guidance or similar experiences from the community would be greatly appreciated. Thank you!