Hello,
I want to call LCM Provisioning workflow to execute my plan without any identity request created. Do we have any argument that needs to be updated within the workflow, so that SailPoint will just execute the plan but not create any identity request.
Thanks in Advance!
Is there a specific reason for choosing this approach? How are you planning to trigger this workflow? From a solution perspective, design a basic workflow that begins with a start step, includes a step to create and execute the provisioning plan, and concludes with an end step.
@ajmerasunny
How do we execute the plan? Do you mean a step with a script containing the Provisioner.execute() logic?
Background-
We use the DUO connector to create DUO accounts, but it uses the /enroll endpoint, which triggers DUO to send registration emails to users. Our client wants to avoid these emails. To achieve this, we removed the “email” attribute from the create provisioning policy. Without an email on the DUO account, DUO cannot send these registration emails, which aligns with our goal. However, the client has now requested that the “email” attribute to be present on the accounts. To address this, I added logic to add back the “email” attribute in the After Provisioning rule. However, we encountered an issue when the After Provisioning rule attempts to modify the account. The operation is unexpectedly changing from “Modify” to “Create,” resulting in the following error: Error code (40003): duplicate resource. It appears there might be a delay in reflecting the account creation in SailPoint. Hence, I added a single-account aggregation step before the email update logic in the After Provisioning rule, ensuring the operation remains “Modify.” While this approach is working as expected, I’m now seeing an org.hibernate.LazyInitializationException error in the logs. To resolve this, I considered launching a workflow from the After Provisioning rule that would create a “Modify” plan to add back the “email” attribute, while avoiding any identity requests creation.
I attached my After Prov rule if you want to take a look at it and suggest any modifications or any better approach than this.
AfterRule.txt (3.61 KB)
Are you using Identity Request Initialize? If yes then there is step called → call:createIdentityRequest which will create the Identity Request. And I agree with @ajmerasunny on what is that specific reason? Because usually it would be better to show things on the IdentityRequest.
Well if its your custom workflow, as @ajmerasunny mentioned, start with the Start step of the workflow with some variables included and then in your second step call the variables and construct a provision plan. For this, see the topic “Provisioning Plan, Account Request, and Attribute Request Relationships” , from the link → https://community.sailpoint.com/t5/Technical-White-Papers/BSDG-4-Bean-Shell-and-the-IdentityIQ-Object-Model/ta-p/75157
And finally call the Provisioner which should be like below:
“Provisioner provisioner = new Provisioner(context);
provisioner.execute(plan);”
But once see if you really dont want to add stuff in your Identity Request or not. Because its good show that things are done on the UI, if you ask me.
@maheshraj9 @ajmerasunny
I provided my reason above on why I m choosing this approach. I would request you to go through that once and provide any better solution.