The error java.lang.IndexOutOfBoundsException: Split resulted in 1 items and you attempted to index at 1 typically points to one of these causes:
Most likely cause: A transform or rule on the disconnected application is using a Split operation expecting multiple values (e.g., splitting on , or ;), but the manual task completion is passing a single value with no delimiter — so the split returns only 1 item and index [1] fails.
Steps to fix:
Check the provisioning policies on your disconnected source for any Split transform referencing index [1]
Verify the manual work item fields — ensure the value being submitted during task completion contains the expected delimiter
Thanks for your response. But from create Account Provisioning Policy , i have configured the account name and account ID (UserLoginID) to UserLogin .
And i am not using any transform here -FYI
Hi @vikaspawar0303
I am trying to test and validate the disconnected application behavior in ISC, so created a source with delimited file connector and loaded some entitlements from the file and also added some user accounts with the entitlements from entitlement file.
now i created a test access profile with one of the disconnected source entitlements and submitted a request for that access profile from request center and after approvals and completing the manual task, i am seeing this error
Check provisioning policy all the provisioning policy i am not sure which operation you are performing so that provisioning policy.
Any custom process you have implemen after request submission , so may be in your org some customization done on after approval or after request submission do this and that , so please check that.
Enable logs and trace.
I think if your provisioning policy correct then some customization only which your org done in workflow mostly in isc
Hello Nayeem. I would first confirm whether the manual task shows Add an Attribute or Create an Account, since they are different operations.
If it is Add an Attribute on an existing account, I would leave the CREATE provisioning policy aside. The error points to a Split transform requesting index: 1 when only one element was produced. I would check for any Split using index: 1, including nested transforms.
If you uploaded the updated CSV before marking the task complete, that upload starts an aggregation, which can trigger identity processing. In that case, I would also check the affected identity’s Identity Profile mappings for the Split.
If nothing turns up there, check the failed Account Activity and aggregation details to help narrow down which attribute was being processed.
If you can share the manual task action and any mapping that uses Split, that should help pinpoint the cause.
The task is Add an Attribute and before marking this task as completed , i have uploaded the updated csv and the account aggregation is successful , as the entitlement got added to user profile but the AccessProfile is not added to his profile . On the other hand , the account activity shows the AccessProfile detected and Create account is passed and there is no Transform used here, still, i am seeing that same error.
Hello Nayeem. Since the task is Add an Attribute on an existing account, I would leave the CREATE provisioning policy aside.
You also confirmed that the updated CSV was uploaded before completing the task, so an aggregation was started. That can trigger identity processing, which updates identity attributes according to their Identity Profile mappings when the identity data is out of sync.
Even if you did not intentionally add a transform to this source, the error strongly points to a Split transform somewhere in the processing path. index: 1 means the Split produced only one element but tried to return the second one.
I would check the affected identity’s Identity Profile mappings, including any nested transforms, for a Split using index: 1. It is also worth checking whether any mapped attribute pulls from this disconnected account and changed during that aggregation.
If you do not find a Split there, check the Aggregation History for any errors or warnings and run an Identity Profile Preview for the affected identity. That can help identify which mapping is producing the unexpected result.
The Roles schema itself looks fine from what you shared, so I would not change the entitlement configuration yet.
If you can share the Identity Profile mappings for that identity, especially any attributes using transforms, that should help pinpoint the cause.
Hey @punna0001
I found that there is a old LCS transform uses a Split transform with index=1. The identity attribute previousLifecycleStates for the affected user currently contains only active, Since there is no comma in the value, the split operation returns only one element:["active"].The transform then attempts to access element at index 1, which does not exist, resulting in the IndexOutOfBoundsException.
This confirms the root cause, and your analysis looks correct.
The NONE,NONE fallback only helps when $oldValue is null. Since previousLifecycleStates currently contains only active, firstValid returns active, and the Split then tries to read index: 1, which does not exist.
I would suggest setting "throws": false on the Split so it returns null instead of failing when the second value is missing.
If you want the result to be NONE in that case, you can add a firstValid after the Split and use NONE as the fallback value.
After updating the transform, I would run an Identity Profile Preview for the affected identity and confirm the value looks correct before retrying the access request.