You will use an Approval Workflow logic when you need to:
-
Build approval or watcher steps for a document.
-
Pre-approve some steps, if they have already been approved in the previous approval process.
-
Logic API
-
Logic Type: Workflow
-
Logic Nature: Default
-
Workflow Type: Determines, for which object this logic will be used. The value is one of WorkflowTypes.
-
Logic Name: If the logic is intended for Quotes you can change its name. For all other workflow types, the logic name must be the same as the workflow type.
-
Execution Types:
-
Standard - to calculate and build the approval or watcher steps for the approval workflow.
-
-
Information provided to the logic
-
Binding variables:
-
workflow: WorkflowDTO - on this object you will build the steps.
-
submitter: Username of the user, who submitted the document.
-
currentWorkflow: InsertWorkflowStepsDTO
-
workflowHistory: WorflowInfo as Map - previously processed workflow, before it was denied. This is available only when an approver denies and then a user submits again.
-
claim | compensation | compensationrecord | contract | customform | dcr | dealplan | model | modelrecord | pricegriditem | pricelist | quote | rebateagreement | rebaterecord: Map - the content of the document to be approved.
-
approvable: Map - the content of the document to be approved. This is an alternative to the previous variable.
-
-
-
Expected logic execution outcome
-
The logic is supposed to build the Steps on the provided WorkflowDTO object. Each step should have:
-
Type: Approver / Watcher
-
Approvers: Either one or more Users, or one or more User Groups (i.e., you cannot mix Users and User Groups).
-
Number of approvers: How many approvers must approve the step, so that it treated as approved. By default, one user is enough to approve the step.
-
Reasons: Reasons why the Users/Groups are requested to approve the document.
-
-
If the logic throws an exception, the workflow steps will not be built and the exception message is displayed to the user. If approval workflow logic was executed during Submit operation, the operation will be canceled.
-
The elements results are not used by the system.
-
Mechanism of Selection, Which Logic Is Used
When an approval workflow logic is about to be executed, the engine will select the logic based on certain criteria. Besides standard things, like if the logic is active, there are also the following aspects that decide, which logic will be used:
-
Type of document - Some types of documents can have the workflow logic set in their Type object:
-
Compensation Plan - Approval workflow logic can be specified in the Compensation Header Type (since version 8.0).
-
Compensation Record - Approval workflow logic can be specified in the Compensation Header Type (since version 8.0).
-
Custom Form - Approval workflow logic can be specified in the Custom Form Type (since version 9.0).
-
Deal Plan - Approval workflow logic can be specified in the Plan Type (since version 8.0).
-
Quote - Approval workflow logic can be specified in the Quote Type.
-
Rebate Agreement - Approval workflow logic can be specified in the Rebate Agreement Type (since version 8.0).
-
Rebate Record - Approval workflow logic can be specified in the Rebate Agreement Type (since version 8.0).
-
-
Logic’s Workflow Type - When the Workflow logic is not set in the Type object, then the workflow logic is selected based on its Workflow Type.
-
Validity - The logic’s Valid After will be compared to:
-
either to today,
-
or, if the advanced configuration property clicWorkflowByTargetDate is set, the system will use the first date of validity of the document (e.g., in a Quote it’s the field targetDate).
-