Approvals

Introduction

MX supports the approval of quotation and workflow based on the rule. It offers defining and maintenance of the rule conditions and rules from the system. To achieve this, the following business types are introduced here:

• Approval Rule
• Condition
• Condition Type
• Rule Status
• Approval Gate Flow
• Approval Gate

Approval Rule

Approval value is a fundamental part of the Approval Engine. It is composed of one (1) or more conditions and one (1) mandatory approval gate. It also has its own status active or not.

• Rule Status:

Available rule statuses are RULE_ACTIVE and RULE_INACTIVE. If the rule status is inactive, the approval rule is not running.

• Condition:

Each approval rule consists of multiple conditions. The rule is fired only when all the conditions are satisfied.

Figure 98 – Condition logic 

• Approval Gate Flow:

“HasApprovalGateFlow” is the outcome of the rule. When the rule is fired, it is the starting point of the whole workflow process. Depending on whom submit the quote, MX will recursively find the approval gate with a higher role according to role hierarchy.

Condition

Condition is the most basic and atomic unit of approval rule and looks like an equation. A condition can be used by more than one (1) approval rules to increase reusability.

Condition Equation

Scenario for the usage of Item 7, 8, and 9:

The administrator wants to define a condition that price item type is “Added Fee” and the base amount value is greater than 30. Since we have different pricing (SSC, ERP), there are several options to make a further filter. 

When the administrator chooses the price item type, UI will automatically show (7) Secondary condition value, (8) Check on Price Item Base Amount (9) Condition Source.

• Attribute

Condition attribute can be any business data attribute and business relation attribute on the quote, SaleItem, DocumentHeaderPriceItem, and ItemHeaderPriceItem. During approval rule firing, the actual value of this attribute is substituted as the left operand.

• Business Type

The domain of condition attribute it belongs to. Currently, the two (2) business types supported are Quote and SalesItem. The condition business type needs to be used either Quote or Sales Item depending on attributes are on Quote level or Sales Item level.

• Search Expression

Search expression is useful if the condition wants to use an attribute that is not shown in the condition attribute. It provides the facility to retrieve data more than the defined types.

• Condition Value

The value that is used to check in the condition as the right operand. Users can input any value regardless of the type. Moreover, MX supports a predefined set of constant values via conditionEnvironmentVariables.

The followings are individuals of condition environment variables:

• VAR_LOGGED_IN_USER

Represent current login user business object

• VAR_LOGGED_IN_USER_ROLE

Represent current login user role business object

• VAR_TODAY

Represent today date

For example, these constant values can be used in conditions such as quote creator must be currently logged-in user or currently logged-in user role.

• Operator

The operator in CPQ is a similar concept to the operator in a mathematical equation. Eight types of the operator are supported as follows:

• equal to
• greater than
• greater than or equal to
• in
• less than
• less than or equal to
• not in

Among these operators, depending on the range of condition attribute, MX supports the operators as shown in the matrix:

Things to Note About:

• In operator is checked for the value IS contained among the given possible values.
• NOTIN operator is checked for the valued IS NOT contained among the possible values.
• >, >=, < and <= operators can be used for only decimal and integer
• Special Condition

Two (2) type of special conditions are providing:

• System Condition

System condition is a condition that is applicable to all rules. Common conditions could be defined as a system conditions.

• TRUE Condition

True condition is a condition whose result is always true. For example, It can be used in a situation where the modeler needs to make a rule true by default.

Approval Gate

Approval gate has a user role who is responsible for the current workflow step and next stage (approval gate) if existed.

Setup steps and UI interaction of Approval

When the quote is in OPEN status, any user can check dynamically what will be the approval flow and who will be the approvers based on the existing quote data and current login user perspective without submitting the quote

Anybody who can update the quote can also submit the quote. Once the quote is submitted, the approval flow is fixed and cannot be changed i.e. the approval gates are fixed. If the workflow has more than one (1) approval gates to go to (in parallel or in sequence), the workflow process will conclude only when all the approval gates are checked (i.e. approval gate owner approved the quote).

• Logging

For debugging and tracing of approval flow on HANA cloud server, the administrator can turn on debug log for the following java class files:

• GetApprovalGatesCommand
• GetApprovalRulesCommand
• AbstractRuleCommand

Setup steps of Approval

Step 1: Define a condition

Step 2: Define an Approval Gate

An Approval Gate can have multiple Approval Gates. This is how it defines approval in sequence for single or multiple roles.

Step 3: Define an Approval Rule and link it with Approval Gate and Condition.

UI Interaction of Approval

Step 1: Under Quote Module > Line Item

Under Quote Line Item, under the discount column then apply the discount.

Step 2: Under Quote Module > Process Flow

After applying, the user submits for Approval for this Quotation

Approvals Directly from Email

Approvals are time critical for providing an outstanding customer experience. Next to the task-driven dashboard mentioned above, MX introduces with the 1908 release a direct email approval functionality. Eliminating the need to log into the application it will speed up quote turnaround times. This feature also meets latest standards on security to prevent misuse. A one-time link is generated that has an expiry time, which can be controlled by an administrator.

This figure shows the Email Approval

Approval Email Template Set Up

Managers can make informed decisions & prioritize approval email in between meetings. Approval reason and rules name are now usable within email templates which allows a manager to understand if it requires urgent attention.

To enable managers getting the information displayed that they already see in the system, it is possible to expose approval rule and condition into the approval e-mail template. 

Configuration

Email templates can be set up with the following information about approval specific values under 'Administration' -> 'Content Management' -> 'conf' -> 'email' where the respective properties files can be maintained.

in which the configuration looks similar to:

It is recommended to simplify the configuration in using a HTML editor if HTML emails would like to be sent, e.g. such as the one below:

Once the new definition of the template is finalized, please make sure to restart the tenant to make changes come to effect.

Valid Parameters

Valid parameters that can be consumed based on approval attribute values are listed below in the table:

Approval Attribute	Format Attribute Name
Rule	approval.rule
Condition	approval.reason

In case the value is not set in the approval attributes it returns and empty string.

In case several rules and conditions apply, all of those will be listed. The approval attributes are being localized into the email recipient's language, if maintained.