Workflow Skipping Step if Same Approver in Multiple Steps

[NateLowery]

I have a workflow with multiple levels/steps. The process type is set to "Pool within level". The problem I'm having is that it will skip a step if the approver from the previous steps is also listed as an approver on the following step.

When I check the request log, it will say something like "Removing 1c0f78f2564d774eb30af0ff7d15d780 from next group index 5 because its pool within group \ next level".

Is there any way for me to work around this issue?

[jdempsey]

This is more or less by design, so finding a workaround could be a bit tricky.  Maybe @CharlesW has come up with a solution to this.  I also feel like this may have been discussed previously in this forum, but I can't seem to find that thread.  In any case, are you using direct user assignments on the workflow steps, or are you using Workflow Groups?  If using direct assignments, could you try creating Workflow Groups for each step and put the same user into each Workflow Group?  You could also try experimenting with AD groups vs. users and see if it makes a difference to reference different AD groups that contain the same user(s).

Hopefully someone else has run into this and solved it already.  I feel like I have in the past, but it's been too long and I just don't remember.  I know one technique that I've used for a similar but slightly different scenario was to add the App Broker service account as an approver (to pause the workflow).  Then I created a PowerShell script that I attached to the "On Approver Approval" event, and that script would "do something" and then approve the request when finished.  You could probably use that approach here, but that seems like a lot of complexity for something that should be more simple.

[CharlesW]

Yes, looking at the code, it is behaving "as designed". I did not spend much time looking over the code (and the approval code is complex), but it looks as if this "should" only happen if the  person that actually approved at the higher level, is also in the list of the approvers at the lower level. In this case it makes sense, otherwise, that approver would get another request for approval notification immediately after approving.  If this is happening even if a different approver approved at the higher level, then I'd consider the design flawed. I can't think of an easy work around. 

[NateLowery]

Thanks for the quick reply.  I am using workflow groups for each step and each of those groups contain a unique AD group with the needed approvers as its members.

After reading your "service account approver" suggestion, I tried adding an extra step in the middle which did work as expected, but I still need some way to auto-approve that step.

I created a new command which runs a PowerShell script to invoke the "approveRequest" API web method and added it to the step as an external action.

The script works, however it "overrides" all subsequent steps and approves the whole request.

Is there some other way I can auto-approve a single step without approving the whole request?

Thanks again for your response. Any other ideas would be much appreciated.

[jdempsey · Accepted solution]

If I remember correctly, the SOAP endpoint in API.asmx will always fully approve the request (overriding any other steps).  Instead, you would need to call the REST endpoint for approvals, which allows you to specify {"overrideApprover":false} in order to approve only the current step.  You just have to make sure the approver specified in the request parameters matches the current approve for the request.

[NateLowery]

Unfortunately we have an App Portal license, not App Broker, which apparently means I cannot access the REST endpoints.

I read in another KB article that "customers can request a license to use the APIs at no additional cost", but according to the Feature Matrix it seems like we would be losing out on some pretty important features if we switched to App Broker.  However, maybe this matrix is outdated, or maybe I'm just not understanding correctly, because I saw in the KB article replies where @CharlesW  stated the following:

"The only difference between App Broker and App Portal (besides the name) is that the REST API is exposed in App Broker.. Integrating with Remedy would require App Broker, since the REST API calls are used.. There should never be a need for you to have an App Portal license at this point. "

Any suggestions on how I should proceed?  Is it just a matter of applying an updated license file?  Or would we have to completely reinstall the product?  Should I open a ticket or contact our sales rep?

[CharlesW]

Thanks for opening a support case for the License file issue.. We'll likely need to open a ticket with our orders team to get a new "App Broker" license issued. Only the App Broker license exposes the REST APIs. 

[jdempsey]

The feature matrix you reference is showing the differences between using Flexera's "App Broker" portal UI versus using the ServiceNow portal UI with App Broker.  This does not reflect differences between App Portal and App Broker, as they are exactly the same product/binaries.  The only difference between them is the license file, which activates the REST APIs for App Broker license files.

Please note that while there is no cost to switch from an App Portal to an App Broker license, there are potentially implications on the way in which the software is licensed.  With the App Portal SKU, Flexera used to offer device-based licensing (though that is no longer true).  With the App Broker SKU, Flexera only offers user-based licensing.  If you currently have an App Portal license that is device-based, you will need to convert to a user-based licensing structure under App Broker.  Please consult with your account manager for more information.