Share all details about your problem, including any error messages you may have received.
Requirement:
We have a custom form where users can request access (e.g., VPN access, USB access, etc.). I want to disable the ability for a requester to approve their own request. Specifically:
If the requester and the approver are the same person, the approval should be escalated to a higher-level manager instead.
In some cases, due to delegation, the same requester and approver may appear. In these situations as well, the request should escalate to a higher-level manager.
Has anyone implemented something similar or can suggest the best approach to achieve this in IIQ 8.4? Any help, examples, or guidance would be greatly appreciated!
IIQ 8.4 doesn’t have a single global toggle for “no self-approval,” but you can implement it cleanly by combining assignment logic, an approval guard, and escalation.
1) Prevent self-assignment up front
In your provisioning approval subprocess (the step that determines the approver), check the calculated approver against both the requester and the target user.
If they match (including cases where the approver is a delegated proxy of the requester/target), route the item to the next manager in the chain.
Keep walking the manager chain until you find a different person, with a fallback workgroup (e.g., Governance/Security) if the chain ends or loops.
2) Block self-approval at the approval step
Add a validation/guard on the Approval step that prevents completion when the current owner of the work item equals the requester or the target (this also covers delegations).
On detection, show a user-friendly message and immediately reassign/escalate to the next eligible approver (manager or fallback group).
This guarantees the rule holds even if someone lands on the item via a direct link or delegation.
3) Configure escalation deliberately
Define an escalation rule/timer that:
Reassigns to the manager-of-manager (or your governance workgroup) if self-approval is detected or the item stalls.
Logs a clear audit comment (“Self-approval prevented; escalated to …”).
4) Apply the same pattern to custom request forms
For your VPN/USB custom form workflow, pass the requester, target, and initial approver into the workflow variables so both the assignment step and the approval guard can evaluate them consistently.
5) Test the edge cases
Requester == target (self-request)
Requester ≠target, but delegation makes them the same as the approver
Direct link to a work item
Manager chain ends / inactive managers → fallback kicks in
TL;DR: Don’t rely on UI hiding. Prevent self-assignment when choosing the approver, and enforce a no-self-approval guard on the Approval step that auto-escalates to the next manager. This covers normal, delegated, and deep-link scenarios.
You can achieve this in Approval Assignment rule, You can write something like this below and try it. It should work.
Identity launcherIdentity = context.getObjectByName(Identity.class, launcher);
String approver1 = attrs.getString("approver1");
String fallbackApprover = launcherIdentity.getManager().getName();
if (approver1 != null && launcher != null && launcher.equals(approver1)) {
log.error("Requester and approver are the same person, escalating to manager: " + fallbackApprover);
// Remove the current approver (who is same as requester)
approvers.remove(approver1);
// Add the manager as approver if available
if (fallbackApprover != null && !launcher.equals(fallbackApprover)) {
approvers.add(fallbackApprover);
} else {
log.error("Manager not found or manager is same as requester, need further escalation");
// You can right line of code if you want to assign it to Admin if manager is nor there.
}
}
Let me know if you have issues in writing it, share me the xml i can update it and share it.
if this post helps, please mark this as solution, as it will help others, if they have same requirements.