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

[Noemi (Noemi Esposito)]

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)

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

   • We see that Account Activity sometimes re-attempts the account create (after refresh/re-evaluation).

   • Is there a supported way to programmatically trigger a retry for specific, known error conditions (e.g., transient data readiness), so that we don’t end up with a failed request but a later, silent success?

2. retryableErrors on the JDBC source

   • Documentation mentions adding connectorAttributes/retryableErrors on a source.

   • Questions for JDBC specifically:

     • Is retryableErrors honored by the JDBC connector for provisioning operations?

     • Are matches substring or exact? Case-sensitive? Any wildcard support?

     • On a retry, does IdentityNow suppress the initial Failed request status, or will the original request remain failed even if a subsequent retry succeeds?

     • Any best practices to avoid cluttering Account Activity with repeated attempts?

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!

[bhaskar-kancherla]

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.

[jsosa (Julian Sosa)]

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

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.

[hyungsunkang93 (Hyung Sun Kang)]

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” 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.

[RAKGDS (Rakesh Bhati)]

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

{

        "name": "email",

        "transform": null,

        "attributes": {},

        "isRequired": true,

        "type": "string",

        "isMultiValued": false

    }