When creating a workflow, it is possible to define denial reasons. The reasons are predefined options for the approvers to choose from or a free text field. Providing the denial reasons can be optional or mandatory.

There are two ways to define the denial reasons: 

• Within a workflow logic using the withDenialReason method. This is applicable for all of the approvable documents. For details see the Denial Reasons in Workflow section below. 

• Price Grid Items can have denial reasons configured even if they do not use workflow. (This is the case of Live Price Grids where the individual items can be approved/denied without an approval workflow – approvability is a property of the LPG items.) Denial reasons for Price Grid Items are defined in Administration > Configuration > Price Setting > Denial Reasons (LPG).

Denial Reasons in Workflow

To define denial reasons for an approval workflow, use the following method in your workflow logic:

This method can be added both on the workflow and workflow step level. If there is no denial reason specified on the workflow step level, the algorithm checks the parent workflow for denial reasons. The Other option is added automatically. The text entered in the Comment field will be displayed together with the selected reason in the Denial Reason column (max 250 characters for the reason and comment combined). 

Once the denial reason is specified, you will get a dialog like this after you click the Deny button:

Open

If isDenialReasonOptional is set to 'false' (denial reason is mandatory), you must select or enter a reason to be able to proceed.

Examples

Example 1 – Defining Global Reasons for the Whole Workflow

Here we have two steps, both inheriting the denial reasons from the workflow itself. The denial reason is mandatory. This configuration is shown in the screenshot above.

Example 2 – Defining Global Reasons with an Override on Workflow Step Level

Here we have two steps, first one inheriting the denial reasons from the workflow itself, the second one has its own denial reason which has a higher priority. The denial reason is mandatory.

Example 3 – Defining Single Step Reasons

Here we have two steps, first one has no denial reasons defined, so there is no user input needed during denial. The second one has its own denial reasons. The denial reason is mandatory.