Limit entitlements selection in Access Request

IIQ 8.3

HI team,

Is there a way to limit the number of items an end user can request on the Manage User access basically in the access request.

In my case if more than 25 entitlements are being requested they are getting failed hence I want to limit the entitlement selection to 20 or so

Thanks

we are limiting no. of entitlements by customizing OOTB LCM workflow. You can add a step , this step will read the plan and if plan has more than 20 adds , you can prompt an error to the user. however, user will need to submit request again with less no of entitlements. Apart from this I don’t think there is a way to limit the no. of adds in the access request.

Hi @gargshub5 ,

you will be able to achieve the goal by using a policy and enable Policy checking in the LCM workflow used for the Access Request.

Best regards,
Daniel

1 Like

any idea about this?

You can modify LCM workflow. Add a new step before step initialize step in LCM. in this new step read the plan. now you can check how many “add” are there in the plan. if your condition meets then move to error step else continue. in the error step you can display why this request cannot be submitted as user requested more than 20 entitlements.
for eg.

<Step icon="Start" name="Start" posX="25" posY="10">
    <Transition to="CUSTOM_STEP"/>
  </Step>

now you can create your own libraries and pass the plan, where you can calculate adds etc etc.

<Step action="script:getAccessRequestErrorMessage(identityName, plan)" name=CUSTOM_STEP" posX="25" posY="10" resultVariable="accessRequestErrorMessage">
    <Transition to="Exit With Error" when="script:null!=accessRequestErrorMessage"/>
    <Transition to="initialise"/>
  </Step>

This would definitely work.
However please take into consideration that there was already effort for the requester to sample together the request.
If now the request just fails the user experience may be negatively impacted.

That’s the reason why we use Policies to achieve the goal and that works really well.

Kind regards,
Daniel