Page Comparison

The Conditional 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

{
  "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:

...

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

Example 1

Anchor
Example_1 Example_1

workflow.withDefaultConditionRecordLogic("DefaultConditionRecordLogic")

Example 2

Anchor
Example_2 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 Conditional Condition Records process functions correctly.

Example

workflow.addApprovalStep("DefaultApproval")
        .withApprovers("user1")
        .withAlreadySatisfied("Reason why it is already satified")
        .setReason("Standard approval")
 
workflow.addApprovalStep("DefaultApproval")
        .withApprovers("user2")
        .withConditionRecordLogic("ConditionRecordLogic")
        .withAlreadySatisfied()
        .setReason("Standard approval")

The Conditional 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.

...