Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

Version 1 Next »

Available from version 14.0

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

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

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:

  1. No steps are defined at all (Example 1).

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

workflow.withDefaultConditionRecordLogic("DefaultConditionRecordLogic")
    workflow.addApprovalStep("DefaultApproval")
        .withApprovers("admin")
        .setReason("Admin approval")
        .withAlreadySatisfied()

  • No labels