Kahua has published updates to the Release Notes for the 2022.8 Release which is scheduled for December 17, 2022. Click the link to access the release notes.  (published November 21, 2022)

Open navigation

Conditonal Approvals

Overview: 

Kahua includes Conditional Approvals in all apps that leverage approvals.  

This article refers to these two support pages 

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: 

  1. Navigate to the proper partition or project.
    1. Note that approval configuration adheres to the Kahua inheritance model. 
  2. 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.

    Graphical user interface 
Description automatically generated with medium confidence
     
  3. Toggle to Override the configuration inheritance, if required.
  4. The existing standard Approval functionality is available, as described on the Approvals support page.


     
  5. 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.

       

  6. Set up a conditional Approval Path
    1. Select Add to create a new Approval Path

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



       
       Table 
Description automatically generated
       
    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 

  1. Select Add to create additional approval paths

  1. NOTE: multiple paths are shown in the screenshot after selecting Add multiple times.
      
     Graphical user interface, application 
Description automatically generated
     
  2. 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> 

<Data Path="Contract.Type" Type="EqualTo" Value="Leasing" /> 

<Data Path="DomainPartition.Type" Type="Contains" Value="Building" /> 

<Data Path="Type" Type="EqualTo" Value="Field Condition" /> 

</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> 

<Data Path="Contract.Type" Type="EqualTo" Value="Leasing" /> 

<Data Path="DomainPartition.Type" Type="Contains" Value="Building" /> 

<Data Path="Type" Type="EqualTo" Value="Field Condition" /> 
</AnyOf> 

 

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

 

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

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.