Share all details related to your problem, including any error messages you may have received.
Hello,
I’m having an issue with access requests with multiple entitlements for the same identity when the approval from various parties is required.
When I create an access request with two entitlements for the same Identity, the second request is only issued after the first one is answered. In the attached image, we see that the current step of the request is No Split Approval and Provision.
Instead of requiring access requests to be accepted one after the other, I would prefer that accesses be allocated to the identity as they are approved.
This is limited to specific uses. The approval process is split for entitlements of the Active Directory, but it is sequential for entitlements of logical applications—the request is sent to the second approver only after the first has made a decision.
How can I ensure that access requests have the desired behavior?
to do that you need to insert the split on the lowest level of approvall that being the manager.
that way in the configuration for split you would put it the “manager” that way it youu split the approvals on the manager level.
I tried setting the approvalSplitPoint as the manager and the owner in a few workflows, but the outcome of either setting still doesn’t create the approvals for both owners at the same time; the approval for the second owner is only generated after the first one is approved.
We have rules defined for the “Omit or Override with Multiple Manager Approval Rule” and the “Omit or Override IdentityIQ 1st Level Business Approvers Rule.” Could this be the cause of the workflow not splitting the approvals?
Is it possible to create a request like the one in the image, with the second entitlement in the same state as the first—that is, awaiting on the owner approval—instead of the “Waiting” state?
Yes, ideally that’s how the request should have been splitted. Do you mind sharing what approvalMode, approvalScheme, and approvalSplitPoint variables you are using?
None of these variables was defined in either of the workflows. I attempted to configure them using the following values:
• approvalSplitPoint=owner
• approvalMode=parallel
• approvalScheme=owner
On the LCM Provisioning workflow the variable approvalSplitPoint is also not set, so I tried setting it to owner. The other variables have the values shown above.
I tried a few different scenarios, but the owner’s approval did not change.
Which workflow should I change in order to get the desired behavior? What values should the variables have in order to obtain this behavior?
set approvalscheme to manager,owner as approvalsplitpoint maps to approval scheme and enable the workflow trace to see if the value of these variables in getting passed along or not.
Does your custom workflow calls the LCM Provisioning? if yes, then that’s all you need as long as these variables are getting passed along to LCM Provisioning workflow. Can you also try using the OOTB LCM Provisioning instead of instead of this wrapper workflow to see if it works with OOTB LCM Provisioning or not?
When the approvalMode is set to serial, as is expected when using serial, the first owner receives the approval, and the second approval is generated only after the first has been answered.
Setting the approval scheme to manager,owner on the Workflow-FrameWork-Wrapper resulted in the previously mentioned behavior. I activated the workflow’s trace variable, but I’m not sure where to look to see the variable values. By default, where are these logs stored?
I would say that the Workflow calls the LCM Provisioning, but I can’t find evidence of this in the XML. Where can I confirm that the workflow in fact calls the LCM Provisioning?
I tried using the OOTB LCM Provisioning for Request Access action, and it produced a behavior closer to what I’m trying to achieve.
The approvals are issued to both Owners at the same time after the Access Request is created.
In order to guarantee that the first entitlement is provisioned even in the scenario that Owner2 has not yet granted his approval, what should I adjust in the LCM Provisioning?
The outcome of using parallelPoll in the OOTB LCM Provisioning is the same as what I noted in my previous reply; Entitlement 1 enters the state of waiting, while Entitlement 2 is awaiting Owner permission.
take a look at your log4j2.properties file to see where logs are routed and enable workflow trace too. Just check how workflows are being called, you should be able to figure out how and from where LCM Provisioning workflow is called. on the OOTB LCM Provisioning workflow, just check what’s the approval mode, should be parallel to trigger workitems in parallel for owner approvals.
I can´t find the log4j2.properties file, but from what I can tell by analyzing the Business Process, the LCM Provisioning workflow isn’t directly called by the Wrapper Workflow, but this workflow has steps defined to calculate the approval types, to split plans, and to provision.
The approvalMode in the OOTB LCM Provisioning is set to parallel. When using the OOTB LCM Provisioning for the Action “Request Access”, the approval is split and the owners receive the approval request at the same time.
The problem is that if Owner1 gives his approval, the provisioning for that entitlement doesn’t start. The provisioning only starts after the Owner2 also gives his approval.
In the Workflow-FrameWork-Wrapper, I found the step “Calculate Required ApprovalTypes” that decides if the workflow is to continue to the step “Split Plan”.
From the tests I conducted, the variable isEligibleForSplit is always set to false, so the next step of the workflow always goes to “No Split Approval and Provision”. What does the function WrapperRuleLibrary.isEligibleForSplit() evaluate in order to determine if the approvals can be split?
Following a few tests with the variables mentioned in this thread, I came to the conclusion that the “approvalMode” and “approvalScheme” did not need to be defined in order for the split to function; instead, the entry “ApplicationBusApprovers” on the “Split Eligibility” just needs to be set to true.
I just ran into another issue with this approach. Requests for entitlements with the same owner are also split, so the owner receives two different work items.
Is it possible to keep the split for entitlements with different owners and join the items for entitlements with the same owner?
