Hello Experts,
Provisioning transactions are created for filtered items that are not actually transactions. They are just stating that an entitlement or attribute exists. Investigation is needed to determine if this should be happening this way, and/or if there is a better way to capture this.
Any idea how to exclude those after provisioning.
Thanks
Hi @niket345 ,
It looks like you are updating the user by adding the user to group (CA_PROV_ACCOUNTS). But already the user had the group and part of the group. That’s why SailPoint will filter it out. This is the expected one only.
Any way to skip this from provisioning transaction if this is already provision.
I think this can be skip by using below entry in the sub process workflow.
<Arg name="noFiltering" value="ref:noFiltering"/>
This has to pass as an argument into the workflow step, which executes the provisioning plan compilation. In the sub-process workflow called “Identity Request Initialize,” there is a step where the plan is compiled into a provisioning project.
You can add to the arguments at this section. Declare a workflow variable called “noFiltering” set to true.
Besides this, please check if those groups are being added by a Provisioning Policy or BeforeProvisioning Rule or any joiners or target mapping, because the application connector need not do re provision again and again. Anyway, SailPoint will do it. But just to check once if you are doing so.
Hi @niket345 ,
Perform a check before you build the plan.
The plan should only consist of the modified attributes.
Thanks
If you want to override the option whatever the default functionality (Filtered), i.e., do not want filtering, then the noFiltering flag needs to be set to true.
I think it would be very difficult to avoid filtering transaction . I would say if you don’t need those better write the period cleanup task / set up perdic process to clean these filtered transaction.
Hi @bhanuprakashkuruva ,
I believe the ask from @niket345 is to exclude them from provisioning transaction and not to override the values on end system.
Thanks
Yeah. So for that, carefully check while preparing the plan if the user had already or not? and make sure the plan contains only newly modified requests.
Yes. my concern is if user have this value then should not come into provisioning transaction.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
