Share all details about your problem, including any error messages you may have received.
Hi Everyone,
I’m trying to implement a use case in SailPoint IIQ where I use a Dummy entitlement to trigger account creation, without actually assigning any entitlement to the account.
What I have Done:
I created a Dummy Entitlement in the application
In the before Provisioning Rule, I’m removing the corresponding AttributeRequest so that the entitlement is not provisioned.
The intention is to keep only the Create Account request.
Issue I’m facing:
After modifying the plan (Creation Scenario):
The AttributeRequest is getting removed as expected.
But the request items are being removed along with the AttributeRequest.
Even though Same behavior is not observed when we try to Modify existing account using same method.
When I use the same with Modify Scenario:
The AttributeRequest is getting removed as expected.
request items stays the same.
The contents of the request item, appearing in the Filtered items
Can you help me here, How can I achieve the same for creation scenario.
This behavior is expected in many cases due to how IIQ handles provisioning plans differently for Create vs Modify operations.
In a Create scenario, the provisioning plan is tightly coupled with the account creation request. When you remove the AttributeRequest (especially if it’s the trigger), IIQ may treat the entire request item as no longer valid, which is why it gets removed.
In contrast, for Modify operations, the account already exists, so removing an AttributeRequest does not invalidate the entire request item, and it can still persist.
For your use case, you may want to consider:
Instead of completely removing the AttributeRequest, try marking it in a way that it does not get provisioned but still remains part of the plan
Alternatively, check if you can construct or retain the AccountRequest explicitly after modifying the plan
Review how the plan is being filtered post rule execution, as IIQ may be cleaning up empty or invalid request items during Create operations
Also, are you using any specific provisioning policy or workflow customization along with this? That might also influence how the plan is processed.
Would be interesting to hear how others have handled similar scenarios.
Could you please elaborate your use case and what is connector type?
If you just want to try Provisioning without entitlement, you can configure Provisioning Policy for Create Operation.
In that Provisioning policy, pass required arguments expected by connector (for testing purpose, you can use dummy values)
Once it is done, you can write Rule to create Provisioning Plan and trigger LCM provisioning or similar workflow. you can also use Provisioner class instead of triggering workflow.
If you want to create access request from IIQ UI, then please check option in Global setting which allows to create Account only without entitlement request. If this option is feasible, you can create access request from UI, otherwise use Rule to trigger access request.
What you’re seeing is expected for Create in IIQ.
If you remove the only AttributeRequest that triggered the request, IIQ can treat the AccountRequest as empty/invalid and prune it during plan filtering. That is why it survives in Modify, but not in Create.
For this use case, I would not rely on a dummy entitlement.
Cleaner options are:
Use a Create Provisioning Policy and send only the attributes the connector really needs.
If users must request it from UI, check the global setting for account-only requests without entitlement.
If needed, build the ProvisioningPlan directly in a rule / Provisioner call instead of creating and then stripping a fake entitlement.
I’m using a JDBC Connector,
And my Use case is to Trigger a create Request for this specific JDBC Application.
I used a Dummy Entitlement to achieve it, but facing the problem as stated above.
I will explore the Global Setting option that you recomended.
@Yukeshk_3006 Create a business role and attach a provisioning policy there for your application, now whenever user request for the role, it’ll trigger the account creation, if account doesn’t exist.
In the policy only add the attributes which you want to provision, if entitlement is not required, don’t add it.
By doing this, user can request it using Manage User Access.
Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(,, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
Hi @Yukeshk_3006, instead of removing the entitlement request in the Before Provisioning Rule, modify your JDBC Provisioning Rule to ignore the request.
,
, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.