[ISC] Configuring Provisioning Retry for Entitlement Requests without Account Creation in Target Systems

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Hi Experts,

Overview
I’m facing a challenge where, due to customer HR requirements, I am not allowed to create accounts on the target system, but I have to continuously retry entitlement provisioning.
I attempted to configure entitlement provisioning retry according to the scenario below, but the retry did not occur at the desired intervals, and the configuration ultimately failed.
What is the correct way to configure provisioning retry? Also, how can I determine the maximum retry count and interval?

Background
In the current customer production tenant, HR 1 serves as the authoritative source for aggregation, and the target system creates accounts based on HR 3.
There is a one-day interval between interfaces for HR 1, HR 2, and HR 3, and the interface flow is sequential (1 → 2 → 3).
Due to this structure, the SailPoint Identity Cube is created first, followed by account creation on the target source.
When the cube user signs into Identity and requests an access profile through an access request, entitlement provisioning may occur.
However, if the HR 3 account information does not yet exist, the account cannot be found, causing the request to fail.
In this situation, I want to configure the provisioning retry interval to match the HR interface time delay.
If the target system’s HR account is not present, the provisioning should retry. The current requirement is to retry at a daily interval for at least five attempts.

Provisioning Retry for Access Request
I reviewed the following documentation on provisioning retry:
:link: How to Configure Retries for Connector Aggregations and Provisioning Actions

I then applied the retry options. However, the provisioning retries did not occur at the desired time or intervals.

[Configured JDBC Connector Options]

Questions

  • Are there any invalid or missing points in my current configuration?
  • I also need to apply the same configuration to a Web Service Connector. If I apply the documented retryable options (common to all connectors) correctly, will that meet the customer’s requirements?
  • Or do different connectors support different retryable options, meaning I need separate configurations per connector type?
  • If there are maximum limits for retry attempts and intervals, will the function work correctly as long as I stay within valid values?

Any advice you can give—on any part of this configuration—would be greatly appreciated.

Regards,

2

If I understood your situation / requirements correctly, I think you can do this via the following configurations:

  1. Map an HR 3 account attribute to an Identity attribute (just for indicating that HR 3 account exists for an identity).
  2. The entitlement(s) / access profile(s) for HR 3 belongs to Segment that has this HR 3 mapped attribute on the identity.

This way, if the self-serve requester doesn’t have an HR 3 account, they need to wait before seeing the entitlement is available for them to request.

(i.e. Forcing the out-of-sequence events into sequence at the request process level, rather than dealing with retries at the provisioning level. Retries in cases where you know it’s going to fail without even needing to try just means you’re implementing a noisy system integration point…and should be avoided if possible.)

You can even add the HR3 mapped identity attribute to an identity attribute change trigger so that you can email-notify the user, if needed, “Hey, your HR3 account is ready, you may request HR 3 entitlements when required”.

1 Like
3

Hi @IIQUserOnCompass Terry,

Thank you for your response.

Although I didn’t mention it in the original post, I’d like to clarify that in our current production tenant, only HR 1 is connected as the authoritative source. At this time, we’re not planning to integrate HR 2 or HR 3, as HR 1 provides the source data, and HR 2 and HR 3 are configured based on the customer’s internal environment and needs.

Your suggestion about controlling access requests using a Segment based on the presence of an HR 3 account is something I hadn’t considered. It does seem like a promising way to prevent requests from failing when the target system account doesn’t yet exist. However, completely restricting access requests based on whether the target system account exists might be difficult for the customer to accept, as it could impact the user experience and perceived service availability. Still, I think it’s a valuable option to bring into the discussion with them as a possible solution.

Thanks again for the helpful insight.

Regards,
Jaewon

4

Hi @jwshin ,

I will suggest to you modify your rule:
in your rule line number 674 capture the response of statement execution and add some conditions for example

int count = statement.executeupdate();
if(count >=1){
result.setStatus(ProvisioningResult.STATUS_COMMITTED);
}
else{
result.setStatus(ProvisioningResult.STATUS_RETRY);
}

if the command executes successfully, it will set the provisioning result committed, else it will re provision the same until statement executes correctly.

And also check your create account configuration in source.

2 Likes
5

Hi @gogubapu Bapu,

Thank you for your response. Based on your advice, I can modify the provisioning rule accordingly.

As you explained, it seems possible to determine whether to return ProvisioningResult.STATUS_COMMITTED or ProvisioningResult.STATUS_RETRY depending on the account creation status when the provisioning plan operation is Create.

By the way, in terms of the ConnectorAttribute configuration in source.xml, is there anything else I should verify or review?
In the attached screenshot, the provisioning rule returned ProvisioningResult.STATUS_RETRY, but the retry did not occur successfully.

Regards,

6

try below code

int count = statement.executeupdate();
if(count >=1){
result.setStatus(ProvisioningResult.STATUS_COMMITTED);
}
else{
result.addError("Failed to provision this request");
result.setStatus(ProvisioningResult.STATUS_RETRY);
}

and
add this error “Failed to provision this request” inside your source retriableError configuration.

7

Hi @gogubapu bapu,

image
image1280×720 167 KB

image
image1041×495 17.2 KB

image
image685×791 41 KB

I modified the result option in the Provisioning Rule and conducted a test, but the retry did not occur.
Is there anything else we should consider to ensure the retry is triggered?

Regards,