Conditonal Approvals

Chase Kopp

Modified on: Mon, Jun 13, 2022 at 5:41 PM

Overview:

Kahua includes Conditional Approvals in all apps that leverage approvals.

This article refers to these two support pages

For more information on Approvals Configuration: Review Workflow
For more information on Conditionals (requires login)

Conditional approvals build on the existing Approval functionality.

Existing Approval functionality allows the system to determine a document’s approver list only based on a given document’s total value.

Conditional Approvals allow approver lists to be determined based on more nuanced conditions than just document value. For example, the system can evaluate a different approver list for a change order related to a construction-type contract vs a change order to a leasing-type contract, plus refine the final approval list based on the change order value.

The criteria available to include in the condition include:

data on a current document
data on a parent document, such as the contract for a change order
data on related documents, such as specific fields on related companies for a contract, and
data on the parent project or program, also known as the “partition”

NOTE: the syntax of the condition relies on standard kBuilder query conventions described in the linked articles, with some examples included below.

Configuration:

To enable and configure Conditional Approval for a document:

Navigate to the proper partition or project.
1. Note that approval configuration adheres to the Kahua inheritance model.
Select the record in the Approvals sub-tab that details the application and approval name to configure. For example, the Expense Contract Signature approval is shown below.
Toggle to Override the configuration inheritance, if required.
The existing standard Approval functionality is available, as described on the Approvals support page.
To enable Conditional Approvals, toggle “Add Conditional Approvals?”
1. This collapses the current approval path to the default approval and allows multiple approval paths to be created.
Set up a conditional Approval Path
1. Select Add to create a new Approval Path
2. Fill in the top four fields specific to “Conditional Approval.”

Field	Description
Order	This describes the sequence each conditional approval is evaluated. The system checks each approval path in order, selecting the first that the condition returns “true.” If you wish to change the sequence, edit the Order for each conditional approval. Duplicates are not allowed.
Description	Summarize the conditional approval path for easy review from the Approval Path grid.
Enable	If enabled, the conditional approval path’s Condition is evaluated for a given document when the Approval is submitted. If not enabled, the Approval Path is skipped and will never be chosen.
Condition	The Condition contains the query used to determine whether or not the approval path will be chosen. The condition is case-sensitive The condition uses standard kBuilder Conditionals syntax – see samples below or Conditionals The condition can test against data on the given document and related contextual data, such as its parent document or current project (partition)
All other fields	See standard approval fields described in Approvals Configuration: Review Workflow

Select Add to create additional approval paths

NOTE: multiple paths are shown in the screenshot after selecting Add multiple times.
NOTE: The Order is essential. Kahua evaluates the Approval Path starting at the top of the list and stops when it finds the first “true” result. This implies a general rule that the more specific a Condition is, the higher in the list it should be. Otherwise, it may never get triggered.

Sample Scenarios for the Approval Path Condition:

The Condition field is an advanced configuration feature. Please review with your administrator for syntax details.

Sample1:

Evaluates whether the Type attribute equals “Field Condition” on the document undergoing the approval process.

Condition syntax: <Data Path="Type" Type="EqualTo" Value="Field Condition" />
Change Order with Type = Field Condition

Graphical user interface, application
Description automatically generated

Sample 2:

Evaluates whether the Type attribute equals “Leasing” on the parent contract of the document undergoing the approval process.
Condition Syntax: <Data Path="Contract.Type" Type="EqualTo" Value="Leasing" />
Change Order with contract type= Leasing

Graphical user interface
Description automatically generated

Sample 3:

Evaluates whether type attribute for document’s parent project Type contains “Building” in it.
Condition Syntax <Data Path="DomainPartition.Type" Type="Contains" Value="Building" />
Project partition with type contains “Building”

Graphical user interface, application, Teams
Description automatically generated

Sample 4:

This sample demonstrates the AllOf syntax, where ‘all of’ the conditions must be met.
Evaluates a change order or pay request that:

The parent contract’s Type equals “Leasing”, AND
The parent project’s type equals “Building”, AND
The parent type equals “Field Condition”

Condition syntax:

<AllOf>

</AllOf>

Graphical user interface, text, application, email
Description automatically generated

Sample 5:

This sample demonstrates the AnyOf syntax, where ‘any of’ the conditions must be met.
Evaluates a change order or pay request that:

The parent contract’s Type equals “Leasing”, OR

The parent project’s type equals “Building”, OR
The parent type equals “Field Condition”

Condition Syntax

<AnyOf>

Graphical user interface, text, application, email
Description automatically generated

For additional information on syntax for Conditionals, see the linked Conditionals. (Login required)

Related Articles