Conditional Approvals

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.

Key things to know about Conditional Approvals include the following:

  • The criteria available to for inclusion in the condition are as follows:

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

    • Data on the parent project or program, also known as the partition.

  • The syntax of the condition relies on standard kBuilder query conventions. Some examples are described below. For more information on conditionals, including the proper syntax, refer to this article on the Kahua Wiki.

    Note If you do not have access to the Kahua Wiki, please reach out to Kahua Enablement at enablement@kahua.com. Note that you will be required to complete certain prerequisites before being granted access to the Kahua Wiki.

  • When creating a set of conditions, the Step number is important. The step number controls the order in which the conditions are evaluated. Kahua evaluates the approval path from the beginning and stops when it reaches the first "true" condition. The implication is that the more specific a condition is, the higher in the list it should be. Otherwise, it may never get triggered.

How to . . .

To add conditions to an approval, complete the following steps:

  1. Review the header to ensure that you are in the correct project or partition. To enable and configure an approval process at the domain level, ensure that you are in the root domain.

  2. Navigate to the Configuration application (Apps > Administration > Configuration).

  3. There are three sub-tabs, Approvers, Approvals, and Project Limits. Select the Approvals tab.

  4. Select the appropriate Application and Approval Name combination. The detail panel opens.

  5. Select Override.

  6. If not already selected, select Enable Approval . For information on completing the approval setup, refer to Approval configuration.

  7. To add conditional approvals, select Add Conditional Approvals?. This closes the default approval path section and instead opens a grid that you can use to create multiple approval paths.

  8. Select Add to add a new approval path.

  9. Enter a Step number and Description. Select Enable to enable this approval. You can leave it cleared until the approval setup is completed if desired.

  10. Complete the following fields:

    Field Description
    Step Enter the number this step is in the process. The first step should be assigned the number 1. The number should be incremented for additional steps.

    Description

    Enter a description that clearly outlines the approval path. This column will appear on the approvals grid.
    Enable Select this option to enable this step. When enabled, the conditional approval path’s Condition is evaluated when the Approval is submitted.
    Condition

    Enter the condition. The Condition contains the query used to determine whether or not the approval path will be chosen.

    The condition can test against data on the given document and related contextual data, such as its parent document or current project (partition).

    The condition is case-sensitive

    The condition uses standard kBuilder Conditionals syntax – see samples below or Conditionals
    Remaining fields

    Complete the remaining fields. For more detailed information on the remaining fields, refer to Approval configuration.

  11. Click Add on the grid to add another approval step. Click Save when you are done.

The following are some sample scenerios you can explore to help you understand how to structure your approval conditions.

This example evaluates whether the Type attribute equals “Field Condition” on the document undergoing the approval process.

Condition syntax:

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

This example evaluates whether the Type attribute equals “Leasing” on the parent contract of the document undergoing the approval process.

Condition syntax:

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

Evaluates whether type attribute for document’s parent project Type contains “Building” in it.

Condition Syntax:

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

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:

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

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:

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