Authorisation Rejections

[Dan Munns]

Hi all,

Is there a way of stopping an authorisation node from fully rejecting if one person rejects the authorisation task?

We use weighting and each person will have the same percentage. At the moment if one person rejects the call (who may only have 10% weighting) the whole call gets closed whereas we want it to be one person may reject it but the other 5 people approve it so the rejection is noted but the vote is still carried.

Thanks

Dan

[Hornbill Staff DR]

Hi Dan,

 the behaviour that you mention is not something that is supported by the authorisation node.

The principle of operation when it comes to the available authorisation mechanisms in Hornbill (currently the authorisation node you mention, and also the new Authorisation Action Item which allows the addition of authorisers on-the-fly) is that it only takes one individual to reject a request/change. The weighting only applies to Approvals.

The explanation behind this design principle is this, if an individual feels strongly enough to reject the authorisation task, then there must be a reason for their decision. Best-practice calls for this reason to be reviewed. If you picture the worst-case scenario, where a rejection is overlooked or not given due consideration, this could lead to a Change being implemented with serious consequences to the business.

In the event of a rejection, a typical Hornbill BPM approval configuration could include a task to confirm if the rejection was valid. If after review, the reason did not call for an outright rejection then the change/request would be resubmitted for authorisation.

Something that may help you is new functionality that has seen the authorisation node recently expanded to incorporate "Tentative Authorisations". While this still operates on the same principle as a "reject" outcome (i.e. weightings do not apply), this allows a third outcome to the authorisation node (default value is "Tentative"). As the name of the feature may suggest, it allows a user to highlight some conditions under-which they would be happy for the change/request to proceed, and gives us the opportunity to create a different path (set of actions) in your BPM that are executed in this scenario (i.e. a branch in the BPM to define what happens in the event of a "tentative" outcome to the authorisation task).

Tentative authorisations can be made available for configuration by enabling the following system setting: experimental.feature.bpm.enabletentativeauthorisations

I hope that helps,

Dan

[Dan Munns]

@DanielRi

Ok thanks for the explanation. I will have a look at the tentative authorisation and adding a fail safe for rejections.

Dan