We’re excited to announce an advanced enhancement for JDBC integrations the rollout of Advanced Low-Code Provisioning. This release makes SailPoint’s JDBC connector provisioning rule configurations more accessible and user-friendly to organizations looking to integrate databases without deep Java expertise.
What is the Problem?
JDBC is among the most adopted connectors for integrating with various databases. However, configuring provisioning rules requires Java expertise and sophisticated customization. Customers had to manually write Java code, define SQL, and build custom provisioning rules to support basic operations across Oracle, MySQL, MSSQL, and other databases.
As customers shift to configuration-centric teams, the need for a simplified, scalable, low-code solution becomes clear.
What is the Solution?
We’re removing complexity by introducing:
UI-Based Configuration
You can now configure key JDBC provisioning operations directly from the UI, while completely avoiding writing Java code
Users can:
Define table names, columns, and SQL logic through a guided UI.
Configure provisioning rules visually.
Support both single and multi-query execution, and stored procedures with input parameters.
Note: To use this feature, ensure Configure Provisioning Operations is enabled in the source configuration page.
Low-Code Provisioning Rules
The new low-code interface supports sql query configuration to achieve:
Create, Enable, Disable, Update & Unlock Account
Entitlement Configuration
Attribute configurtaion
Single or multiple SQL query execution
Stored procedure calls
Inline variable substitution
Example:
UPDATE users SET first_name = $plan.firstName.string$ WHERE id = $response.id.int$
This model allows full flexibility while maintaining a user-friendly, no-code interface that ensures control, reusability, and security.
Availability: Release Information & Documentation
The new features are available in ISC JDBC connector and are applicable to both existing sources and new integrations.
Great functionality, very useful. One question, if we enable “Provisioning Query Settings”, will the parameter in the “jdbcProvisionRule” connector continue to work as well? In a hybrid way?
Thank you for this major step forward in simplifying database integrations through the Advanced Low-Code Provisioning enhancements for the JDBC connector.
JDBC has always been one of the most versatile and widely used connectors for custom database integrations. However, its power came with a high barrier to entry, requiring Java expertise and deep familiarity with SailPoint provisioning rule structures as you rightly pointed out. This new low-code model significantly lowers that barrier, enabling to manage database provisioning securely and efficiently without writing custom Java code.
The UI-based configuration, support for stored procedures, inline variable substitution, and ability to chain multiple SQL queries offer a powerful yet approachable provisioning experience.
As a suggestion it would be valuable to include predefined templates or provisioning rule snippets for common RDBMS platforms like Oracle, MySQL, PostgreSQL, and MSSQL.
Looking forward to enabling this in JDBC sources and exploring its full potential.
That is great feature, but can the connector handle natively “Date” type formats? As date is not a valid data type in account schema, when I am trying to update a “date” field on the table the value that I am trying to provision is interpreted as a string.
Is there any work around that? Since we cannot “typecast” in the “update account” section.
For just about every operation except Account Update / Attribute Sync, you can reference values with the Date type when building your query / stored procedure call. This seems to expect date strings to be in the yyyy-MM-dd Java date format.
For example on account creation, $plan.START_DATE.Date$ will convert a string with yyyy-MM-dd date format in the provisioning plan into a java Date object when building the resulting JDBC statement.
For Account Update / Attribute Sync, we chose to use a Before Provisioning rule to convert the yyyy-MM-dd string dates to the native string date format expected by the database. We were using Oracle Database, so it was dd-MMM-yyyy in our case.
Requiring a Before Provisioning rule to handle dates somewhat defeats the purpose of this low-code feature, though.
Example: