Error in authorisation process

[QEHNick]

This is the first time anyone has  REJECTED an authorisation in one of our BPs.

However we get this error in the process. I need a degree in Hornbillism to be able to understand it. Any ideas what I've done wrong?

Xmlmc method invocation failed for BPM invocation node 'stage-9b05253c/flowcode-d60b4d9c': <methodCallResult status="fail"> <state> <code>0207</code> <service>apps</service> <operation>getAuthorisationOutcomeDetails</operation> <error>/apps/com.hornbill.core/flowcode/fc_modules/xmlmc.js(189): error X1001: Uncaught EspMethodCall::invoke: Operation[data::queryExec] The user &apos;40A95AC2-25B3-4FA6-B4AC-8D7C1FBBEEBF&apos; has the application privilege level &apos;basic&apos; but requires &apos;user&apos; to invoke this stored query: bpmUtility.GetLastAuthTaskId</error> <flowcodeError> <where>Execute</where> <filename>/apps/com.hornbill.core/flowcode/fc_modules/xmlmc.js</filename> <lineNumber>189</lineNumber> <columnPos>20</columnPos> <message>Uncaught EspMethodCall::invoke: Operation[data::queryExec] The user &apos;40A95AC2-25B3-4FA6-B4AC-8D7C1FBBEEBF&apos; has the application privilege level &apos;basic&apos; but requires &apos;user&apos; to invoke this stored query: bpmUtility.GetLastAuthTaskId</message> <errorCode>1001</errorCode> </flowcodeError> </state> </methodCallResult>

[James Ainsworth]

Hi @QEHNick

7 hours ago, QEHNick said:

&apos;basic&apos; but requires &apos;user&apos; to invoke this stored query: bpmUtility.GetLastAuthTaskId

This seems to suggest that someone that is only a basic user has managed to progress the workflow to this node.  The workflow is running in the context of the basic user, who doesn't have the rights to get information about task outcomes.  Some automations are able to "self-elevate" to the correct application privilege, but it doesn't look like this one can.

Without seeing your workflow, I'm assuming that before the Get Last Authorisation Details automation node, you may have another node, most likely a suspend node, where coming off of suspend can be triggered from an action by the customer (who is likely to be a Basic User) and the BPM continues in the context of that user when it reaches the Get Last Authorisation Details node.  A workaround can be to put a Hornbill Automation that returns the user context to the system immediately before the Get Last Authorisation Details.  I believe you can use the Await Expiry automation to do this.  The shortest time that you can set this for is 1 min.  Alternatively, just make sure that the Get Last Authorisation Details node is preceded by a task or suspend node that can only be completed by a full user.  

 

I hope that makes sense.  Let us know if you have any questions about this.

[QEHNick]

Thanks James, does this mean I am using the wrong authorisation type? I want my customer (manager)  to be able to authorise a request put in by another cusotmer.

[James Ainsworth]

Hi @QEHNick

Hard to say without seeing your entire workflow.  Rule is that if you are asking a Basic User or External Contact to authorized something, you need to use the External Authorization.  If you are asking a User with a licensed subscription to Hornbill to authorizes something, you can use either the standard Authorization or the External Authorization.  Using the standard Authorization does have some added benefits and features available to Hornbill Users.

 

If you are using the correct authorization node already, then my previous note about user context will need to be looked at.  

[QEHNick]

I've been advised to log a ticket about this before I make any radical changes. The process was working for the last month or so.

[James Ainsworth]

10 hours ago, QEHNick said:

The process was working for the last month or so

Definitely.  If it was working before, and stopped working without you making any changes to the workflow, then worthwhile raising with support.  Without making any changes to the workflow, it is possible that things still go wrong.  For example you may have a full User that is receiving  BPM authorisations, but then their account is change to a Basic account with their name still linked to the authorisation.  So, a change in environment can also have an impact.

[Steve Giller]

Just to close this off, the issue wasn't with the Authorisation itself, the External Authorisation was working as expected, however a subsequent node that works in tandem with the Authorisation Task (rather than the External Authorisation) which was only activated by a rejection was used, and this caused the error.

This node has been removed and the Workflow is now progressing.