We have marked one of the account attributes JOBD as entitlement on the source.
Basically, when it reads (aggregates) the account the entitlement value comes with some extensions (example: /QSYS.LIB/CLMPRDOBJ.LIB/CLMJOBD.JOBD), but the application team confirmed that the value should look like (CLMPRDOBJ/CLMJOBD).
The real problem arises when we want to create an account and provision this access.
The value goes in the provisioning plan is (example: /QSYS.LIB/CLMPRDOBJ.LIB/CLMJOBD.JOBD) and it fails because the connect expects the value as (CLMPRDOBJ/CLMJOBD). When we pass the expected value from create provisioning policy as a static value it works, then when it reads it, it will read with all those extensions.
We do not have expert hours to deploy BP rule, where we could change it to what it expects.
I could have used BuildMap rule if it was supported to this connector.
Is there any filter option available on this connector?
I need your thoughts on this; please share what options we have or can explore.
If you dont plan to sync that attribute and use it only for provisioning, then try using a transform in the provisioning policy to modify the value for that attribute
How would that work in this case? Since JOBD is configured as an entitlement attribute at the source account schema level, the entitlement values are automatically attached to the account during aggregation.
Entitlements do not appear as editable fields in the Create Provisioning Policy, so there is no direct place to apply a transform there. ISC automatically adds the entitlement values to the provisioning plan based on the entitlement configuration on the source’s account schema.
The issue here is that aggregation brings the value in fully qualified format: /QSYS.LIB/CLMPRDOBJ.LIB/CLMJOBD.JOBD
whereas provisioning expects: CLMPRDOBJ/CLMJOBD
So unless the connector supports some normalization/filtering mechanism during aggregation or provisioning, I am not sure how a provisioning policy transform alone would modify entitlement values before they are sent in the plan.
@shekhardas1825 Maybe the practical approach here would be using a Before Provisioning rule on the connector and adding BeanShell logic to fetch the entitlement value from the provisioning plan and tweak it before sending it to the target system.
Since the application team has already confirmed that they do not actually use or recognize the extension format (/QSYS.LIB/...JOBD), modifying the value during provisioning may be the safest option here.