Idea ID: 2878612

Add REMOVE_APPLICATION_FROM_USER to Entitlement Fulfiller

Status: Needs Clarification

  As Jim outlined, not all of the possible fulfillment actions are available for every Fulfiller.

For Example, the LDAP (eDirectory or Active Diretory) and the IDM Entitlement Fulfiller do not have the option to perform "Remove User Access to Application".

The ENUM doc has a one line description of each action:


From the above doc:

"REMOVE_APPLICATION_FROM_USER – Remove user from their accounts in an application"

We will follow-up to understand more of your use case related to the "Remove User Access to Application" action.

Steven Williams
Principal Enterprise Architect
OpenText Cybersecurity

See status update history

the provided Entitlement Fulfiller is able to grant accounts and permissions to an identity. It also revokes permission from an identity. But currently it doesn't support revoking accounts from identities.

Revoking accounts from identities automatically would make sense to provide a whole account lifecycle. Currently the last bit, revoking accounts, is missing to build a full account lifecycle which entitlement enabled drivers. The revoke should just set the account entitlement to status "0".


  • I agree :) At least this is an unexpected behavior as mostly everything is fulfilled automatically but this last bit has to be handled manually. But after some discussions I was specifically asked to create an enhancement request.

  • The issue is not really which change type the fulfiller supports. The issue is that revoking a role results in a different change type than a review action and there is no way to control this.  The desired action on the entitlement is the same. We want to entitlement ref to set to status "0". the driver will then do whatever it likes based on that.  

    It makes no difference how we get there. Have the fulfiller support both, Allow us to configure which is sent, Make it consistent between a review and role revocation... etc.  BTW, what is the difference in the actions and why is one used in one case and not the other? 

    Not being able to take action at all is a defect.  In this case, there is only one OOTB fulfiller to choose from. I'll write a custom one if I have to but I should not need to do so.

  • I disagree.  All fulfillers do not implement all change types.   There is no guarantee that the fulfiller target you choose for an app implements the changetype you need.   I think part of implementation is to ensure for the changetypes you are going to need, that the fulfiller you choose handles it.   In my mind its an enhancement to enable the Entitlement fulfiller to handle the additional use cases.

    That being said, I'd love for this to be added if we call it a defect or an enhancement.  I'm not sure if the label actually impacts when we'd see an update.   In a perfect world, every fulfiller would handle every type, but I think we are a ways away from that.  At this point you have to be cognizant of it.


  • This is NOT an enhancement. This is a defect in basic functionality. When a role revocation results in a loss of access, the system should be able to fulfill the access revocation. In this case, the fulfiller does not support the action type so it ends up in the manual fulfillment queue.

  • Uff... this would mean that the entitlement fulfiller will fulfill the remove automatically if requested by a review and will not fulfill the remove automatically if requested by a business role (or better said by the loss of a business role).

    That doesn't sound consistent Disappointed