# IdentityNow JDBC — Role is granted even when provisioning fails (rollback/retry guidance?)

**URL:** <https://developer.sailpoint.com/discuss/t/identitynow-jdbc-role-is-granted-even-when-provisioning-fails-rollback-retry-guidance/184253>\
**Category:** SHF Discussion and Questions\
**Tags:** jdbc-connector, roles, sailpoint-identity-security, provisioning\
**Created:** [October 2, 2025, 7:59am UTC](https://developer.sailpoint.com/discuss/t/identitynow-jdbc-role-is-granted-even-when-provisioning-fails-rollback-retry-guidance/184253 "2025-10-02T07:59:22Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Noemi](https://avatars.discourse-cdn.com/v4/letter/n/7ab992/32.png) [@Noemi](https://developer.sailpoint.com/discuss/u/Noemi)\
**Post date:** [October 2, 2025, 7:59am UTC](https://developer.sailpoint.com/discuss/t/identitynow-jdbc-role-is-granted-even-when-provisioning-fails-rollback-retry-guidance/184253/1 "2025-10-02T07:59:22Z")

</div>

**Environment**

- Product: IdentityNow (Identity Security Cloud)

- Source type: **JDBC**

- Customization: **Connector Rule** involved in account create

**Use case / problem**  
When we request a role that should create an account on the JDBC source, IdentityNow appears to treat the flow in two separate phases:

1. Assign the **role** to the identity

2. Start **provisioning** (account create on the JDBC source)

If the provisioning step fails (e.g., an exception during the INSERT executed by the connector rule), the **request ends in Failed status**. However, the **role remains granted** on the identity even though the related **entitlements/accounts are not created**. In other words, the identity shows the role but does not have the expected access on the target.

**Example error (from Account Activity → Process)**

```auto
java.lang.IllegalArgumentException: Error during the creation of the account IT Cyberark:
the email is null or MISSING@MISSING.COM

```

**Observed behavior**

- Request timeline shows “Request submitted → SoD Check → Provisioning → Request failed”.

- On the identity, the role is already present (granted before provisioning), but no entitlement/account exists.

- We also notice that subsequent **Identity Refresh** or certain events in **Account Activity** may **trigger a new attempt** to create the account, as if the role were re-evaluated.

**What we expected / question**

- Is this two-phase, non-transactional behavior expected for role assignment vs. provisioning on JDBC?

- Is there a recommended **rollback pattern** (e.g., automatically remove the role if provisioning fails), or a best practice to keep roles and downstream access in sync when provisioning errors occur?

**Ideas we’d like guidance on**

1. **Retry approach**

2. **`retryableErrors` on the JDBC source**

**What we’ve tried / considered**

- Verified that failures originate from the INSERT executed in the connector rule (e.g., missing email).

- Confirmed the role remains on the identity after the request fails.

- Considering `retryableErrors` vs. relying on Account Activity/Identity Refresh to re-evaluate.

**Goal**

- Either (a) a **supported rollback** mechanism that removes the role when provisioning fails, or

- (b) a **supported retry** mechanism for known, transient errors—ideally without leaving the role permanently assigned while access is missing.

Any official guidance, best practices, or implementation patterns for JDBC sources (and connectors with custom rules) would be much appreciated. If needed, I can provide sanitized screenshots of the request timeline and the identity’s access view.

Thanks!

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/2/2/22374fd9178aedb0df03b31de8bf35d5e4792bfa.jpeg)

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/b/f/bf041e44a8a1aa5182dd74a3b79ca04695894930.png)

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/9/9/99fd422990e6814802c20ffb7e6a2d059eddc4ca.png)

---

<div class="post-metadata">

**Author:** ![bhaskar-kancherla](https://avatars.discourse-cdn.com/v4/letter/b/bc8723/32.png) [@bhaskar-kancherla](https://developer.sailpoint.com/discuss/u/bhaskar-kancherla)\
**Post date:** [October 2, 2025, 3:56pm UTC](https://developer.sailpoint.com/discuss/t/identitynow-jdbc-role-is-granted-even-when-provisioning-fails-rollback-retry-guidance/184253/2 "2025-10-02T15:56:27Z")

</div>

Here, You have requested for a role which intern provisions the account to target once the role request is approved, which invokes the JDBC Provisioning rule to create the account on the target. if the account creation fails, you can retry the Operation in the JDBC Rule itself. There is no ootb configuration which retries.

As far as the role removal. Automatically it doesn’t happen because the role assignment is request based. IdentityNow keeps on re-trying till the account creation is successfull. Please validate your before provisioning rule to make sure all the attributes are passed to make the account creation successful.

---

<div class="post-metadata">

**Author:** ![jsosa](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/jsosa/32/31578_2.png) [@jsosa](https://developer.sailpoint.com/discuss/u/jsosa)\
**Post date:** [October 2, 2025, 4:13pm UTC](https://developer.sailpoint.com/discuss/t/identitynow-jdbc-role-is-granted-even-when-provisioning-fails-rollback-retry-guidance/184253/3 "2025-10-02T16:13:13Z")

</div>

Hi Noemi, this is an expected behaviour. Identity is assigned some role, and this is independent of entitlement being assigned with success (or not).

You can configure maxRetryCount attribute on source (via API or VSC), you can find more details in

> **[Retry Configurations](https://documentation.sailpoint.com/connectors/jdbc/help/integrating_jdbc/retry_configurations.html)**
>
> SailPoint Connectors Documentation

As role assignament and entitlement provisioning are independent events, they can not be configured as one transaction.

Perhaps you can catch provisioning failure with the provisioning completed trigger in workflow, and perform some action on this.

---

<div class="post-metadata">

**Author:** ![hyungsunkang93](https://avatars.discourse-cdn.com/v4/letter/h/bc8723/32.png) [@hyungsunkang93](https://developer.sailpoint.com/discuss/u/hyungsunkang93)\
**Post date:** [October 2, 2025, 4:41pm UTC](https://developer.sailpoint.com/discuss/t/identitynow-jdbc-role-is-granted-even-when-provisioning-fails-rollback-retry-guidance/184253/4 "2025-10-02T16:41:07Z")

</div>

Yes, this two-phase behavior is expected in ISC. Role assignment and provisioning are separate processes by design, so there’s no automatic rollback when provisioning fails. This actually prevents users from having to re-approve requests during retry scenarios.

For your specific error with the email validation, the JDBC connector does support retryableErrors. You can configure this in your source’s connector attributes using substring matching (case-insensitive). Add something like “IllegalArgumentException: Error during the creation” and “email is null or [MISSING@MISSING.COM](mailto:MISSING@MISSING.COM)” to the retryableErrors array. The original request will stay in “Processing” status until it either succeeds or exhausts all retry attempts.

However, I’d recommend tackling this from two angles. First, add a Before Provisioning Rule to validate the email field before attempting the INSERT operation. This prevents the error from occurring in the first place by checking if the email is null or contains “MISSING” and throwing a proper ConnectorException early. Second, you could implement a cleanup workflow triggered on Access Request Completion that checks if provisioning failed and removes the role if no accounts were actually created.

The Account Activity re-evaluation you’re seeing after Identity Refresh is normal ISC behavior. When it detects incomplete provisioning (role assigned but no corresponding accounts), it will attempt to reconcile this during refresh cycles. This explains the “silent success” scenarios you mentioned.

The retryableErrors approach is probably your best bet for handling transient data issues while maintaining the role assignment, but combining it with better validation and a cleanup workflow gives you the most robust solution.

---

<div class="post-metadata">

**Author:** ![RAKGDS](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/rakgds/32/2795_2.png) [@RAKGDS](https://developer.sailpoint.com/discuss/u/RAKGDS)\
**Post date:** [October 4, 2025, 1:26pm UTC](https://developer.sailpoint.com/discuss/t/identitynow-jdbc-role-is-granted-even-when-provisioning-fails-rollback-retry-guidance/184253/5 "2025-10-04T13:26:35Z")

</div>

Can we try to make the email address field mandatory in Provisioning Policy ?

{

```
        "name": "email",

        "transform": null,

        "attributes": {},

        "isRequired": true,

        "type": "string",

        "isMultiValued": false

    }

```

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/sailpoint/original/2X/f/f2136700ed5e3703e0b85e02f6be799dacca7735.png) [@system](https://developer.sailpoint.com/discuss/u/system)\
**Post date:** [December 3, 2025, 1:27pm UTC](https://developer.sailpoint.com/discuss/t/identitynow-jdbc-role-is-granted-even-when-provisioning-fails-rollback-retry-guidance/184253/6 "2025-12-03T13:27:17Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.