If the violation was triggered by a request, then the assignment never really existed so nothing to do.
In the case of an existing violation, the system does not remove something automatically because it cannot decide which system role - in your case is more important than the other.
Or, let's think about different ways to receive a system role (inheritance, request, etc.). Sometimes it is impossible to remove the system role membership without loosing additional permissions which might be unwanted.
That's why there is the new Compliance Violatin Removal Wizard in the Web Portal of version 8 that helps the Exception Approver in resolving the violation.
My understanding is from front end, whenever the user requests for entitlement, respective workflow gets triggered and whatever is there in the workflow, it gets executed. For compliance check, I need to add CR approval procedure and Exception approval procedure in the next step so that Exception approver can approve/deny the request. In this case, compliance rule violation comes as "Pending request" for the exception approver and not in "Pending rule violation" so violations comes in "Pending rule violation" only when rule is violated through backend. Let me know if my understanding is correct.
If yes, then I think I don't need Approve/ Deny action in "Pending Rule violation" tab
No but I want the exception approver to act on the violated rule. If the request is through front end, it comes as pending request for the exception approver and Approve/Deny works properly there but through backend it comes as Pending Rule violation and there Approve/Deny does not do anything. So if in pending rule violation exception approver can't Approve/Deny and he can just Resolve it then what is the point in keeping Approve/Deny option there
