Condition Records Approval

Available from version 14.0

The Condition Records Approval feature allows the system to create Condition Records automatically when an object is moved to the Approved status, ensuring that every approved object generates the corresponding Condition Records. Additionally, it facilitates the manual invocation of the Condition Record creation logic upon an object's approval. This approach also applies to the denial and recalculation of contracts once they have been approved.

No Workflow Logic Defined

This use case describes a scenario where, in the absence of any defined logic or when using Live Price Grid with Auto-Approve, it is essential to establish a defaultConditionRecordLogic for various approvable domain objects. An Advanced Configuration Option, conditionRecordLogicsWhenNoWorkflowDefined, will function as a map to specify Condition Record Logic names for different entities. These defined logics will be utilized during submission when no Workflow Logic is available, enabling the execution of fallback logic as necessary. An example of such value could be:

Example

Name	Value

Name

Value

conditionRecordLogicsWhenNoWorkflowDefined

{
  "pricelist": "DefaultCRLogic",
  "quote": "DefaultCRLogic",
  "pricegriditem": "DefaultCRLogic",
  "calculationgriditem": "DefaultCRLogic",
  "rebateagreement": "DefaultCRLogic",
  "contract": "DefaultCRLogic",
  "dcr": "DefaultCRLogic",
  "rebaterecord": "DefaultCRLogic",
  "modelrecord": "DefaultCRLogic",
  "claim": "DefaultCRLogic",
  "model": "DefaultCRLogic",
  "customform": "DefaultCRLogic",
  "compensation": "DefaultCRLogic",
  "compensationrecord": "DefaultCRLogic",
  "rebaterecordgroup": "DefaultCRLogic"
}

Workflow Logic without Single Step

This use case addresses scenarios where a workflow is defined but contains no steps or does not return any steps. Default Condition Logic must be established in these cases. There are two options for this situation:

No steps are defined at all (Example 1).
Some steps are defined, but they are not returned; for instance, the workflow formula evaluation results in zero steps (Example 2).

In such instances, the ConditionRecordExecutor is used to initiate the process, with the definition derived from the withDefaultConditionRecordLogic() method.

Example 1

workflow.withDefaultConditionRecordLogic("DefaultConditionRecordLogic")

Example 2

workflow.withDefaultConditionRecordLogic("DefaultConditionRecordLogic")
 
 if (false) {
 workflow
 .addApprovalStep("Calling Sales Manager 1")
 .withApprovers("sales_manager")
 .setReason("Reason!")
 }

Workflow Logic Defined with All Steps Satisfied

This use case describes a scenario in which workflow logic consists of steps that are all marked with .withAlreadySatisfied. In this situation, the definition should be sourced from withDefaultConfigurationLogic(). During the submission of an item, it is essential to create and pass the ConditionRecordExecutor to the process, rather than leaving it null. This ensures that the Condition Records process functions correctly.

Example

The Condition Record logic will be defined at the final step, or the Default Condition Record logic will be set using workflow.withDefaultConditionRecordLogic("DefaultConditionRecordLogic") as shown in the example below.